BSC_Tests: sprinkle logs to illustrate what the dyn PDCH tests expect.
BSC_Tests: tweak comment to mention that inter-BSC HO MT *does* allow N-CONNECT
from MSC.
f_tc_assignment_fr_a5_1_codec_missing: mark the missing IE beyond doubt.
Change-Id: I93c2914e766e200d89308cc81dd803e939b9b28c
Sometimes TC_chan_rel_hard_rlsd_ms_dead could fail because the Immediate
assignment command would arrive in the RSL queue after it was cleared in
f_expect_chan_rel. The alt statement would now never complete since the
Immediate Assignment was blocking/hogging the queue. Wait explicitly for
the IMM ASS in f_chreq_act_ack before continuing.
Change-Id: I2831d4caf7f045b3396d28a978328e8a1097d8d3
Sometimes (under heavy load and when the last paging cmd arrives near
the reset ack) some messages are not enqueued in the IPA_RSL port after
we have received the reset ack from BSSAP.
In the failures I have seen wireshark reports that no paging cmd arrived
after the reset ack, see jenkins job 285:
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/285/
Adding a sleep is always a bit crude, but since the paging cmd is
scheduled through TCP while the reset ack is sent through sctp I don't
see another way.
Running the test under load in a loop showed improvements where I was
not able to reproduce the failure with this patch.
Change-Id: Ib2d60e2c59baf98e437e078d844adcc6dbdbfcd8
Pass the CTRL_DETECT_CONNECTION_ESTABLISHMENT_RESULT parameter to
the TELNET port by default. This allows tests to make progress
into an error handling path if they are started while the osmo-*
program they want to connect on VTY is not running.
Observed with osmo-ggsn tests, where if the one test runs
into a VTY connection failure the subsequent test would get
stuck forever in a map() call on the VTY TELNET port.
Teach the function f_vty_wait_for_prompt() about connection
reports by the TELNET module. We may now receive an integer which
represents the socket file descriptor for the telnet connection.
This case was not handled by the previous change made in
commit cb111b21ab. As a result,
BSC tests started failing with "VTY Timeout for prompt" because
the alt-statement in f_vty_wait_for_prompt() would not progress
past the integer sitting on the VTY port's receive queue.
Change-Id: I56925f93af6c55e93f3f417099db135744da6a40
Related: OS#3149
With this patch, I see all ttcn3-bsc-tests failing with
"Verdict: fail reason: VTY Timeout for prompt"
This reverts commit cb111b21ab.
Change-Id: I215d7ab5eee75cf6d3afaac760af64356c943140
Pass the CTRL_DETECT_CONNECTION_ESTABLISHMENT_RESULT parameter to
the TELNET port by default. This allows tests to make progress
into an error handling path if they are started while the osmo-*
program they want to connect on VTY is not running.
Observed with osmo-ggsn tests, where if the one test runs
into a VTY connection failure the subsequent test would get
stuck forever in a map() call on the VTY TELNET port.
Change-Id: I9acf7793d5d68aec6d087cff254a10d8b673dab1
Related: OS#3149
It seems mtc.stop() alone does not really solve the race conditions when
shutting down components. The error happens when messages are sent on
ports which are no longer connected since the receiving component has
terminated.
Some web search
http://www.ttcn-3.org/TTCN3UCAsia2007/Presentations/TTCN3%20UC%202007%20Concurrent%20TTCN.pdf
suggested that one should stop all components before
calling mtc.stop (slide 38). Slide 33 also mentions the difference
between .stop and .kill. Kill removes the port connections while stop
does not. And I think looking at the logs when the testcase teminates
(through mtc.stop or otherwise) it is internally calling kill on all the
components. So hopefully stopping all components and then stopping the mtc
will fix this nasty issue.
I verified locally that the situation improves between commits now when
running BSC_Tests.TC_paging_imsi_nochan_all 20 times in a loop and
otherwise generating load on the system. It reliably failed before this
patch and I wasn't able to get it to fail with it.
Change-Id: I398883492919ceabcf94b5cc2361c63ec772d9d5
This test suite acts as an SCCP server on top of M3UA.
SCCP tests are run against the sccp_demo_user program which
can be found in libosmo-sccp/examples. This program must be
started in client mode: sccp_demo_user -c
The SCCP test suite should then work out of the box with
the provided SCCP_Tests.cfg file and this additional change
to sccp_demo_user default point codes:
https://gerrit.osmocom.org/#/c/libosmo-sccp/+/9652/
There is currently only one test, for the libosmo-sccp crash
reported as issue OS#2666. The implementation of this test
is currently using an ugly workaround due to shortcomings of
the M3UA Emulation layer (see source code comments). Whether
a better solution is feasible is still to be determined.
The test requires a patch to the SCCP Protocol Emulation which
has been submitted upstream: https://git.eclipse.org/r/#/c/124552/
Change-Id: I03f5e8b282a7396b45417495c88d8fb81b26cda8
Related: OS#2666
Call mtc.stop after setverdict(fail), add reasons to most failures and
fail with verdict error for internal errors.
Change-Id: I9b618235939fa41160b9be6677b121963d3ec857
The IPACC and MDCX interaction happens nearly in parallel to the
normal RSL connection that handles the handover, in particular the
channel relase from the old BTS may arrive in between IPACC and MGCP
operations.
- When the channel release arrives, check if MGCP and IPACC
operations are done (we have seen one MDCX on MGCP and an CRCX
plus an MDCX on IPACC level)
Change-Id: I207e9ece48ec53f872f82d981435cee7c2d0b094
Related: OS#3396
The function f_check_mgcp_expectations() checks the counters that
count the occurrence of MDCX and CRCX messages against computed
expected values. At the moment it is not easy to spot where exactly
the deviation occurred. Lets add some log output so that we can see
which type of message on which connection was missing or too much.
Also add a string parameter that is set to the calling functions
name so that we know from where the check has been triggered.
- Add more verbose log output for counters
- Add parameter to prepend to the log line
Change-Id: Ida0eba4ef3c1db977d392267ef76ec37b87133b3
Related: OS#3292
The function f_establish_f_establish_fully does not yet handle the
case where calls get switched locally. In those cases we expect to
see one additional MDCX before the BSSMAP ASSIGNMENT COMPLETE is
sent.
- Check exp_ass_cpl if the call is expected to be LCLS and expect
another MDCX for those cases.
Change-Id: I55fae5ab03980cd810ed7dc38208550686b1659e
Related: OS#3292
as_media handles the MGCP interaction for most of the tests. However,
it does not make sure if transactions are missing or if too many
transactions are performed (e.g. if an SCCP-Lite tests still creates
the connections pointing to the core network, even if they must not
created by the BSC in this case). So lets make sure that the MGCP
transactions are performed as expected by counting them.
- Add counters to count CRCX and MDCX transactions
- Check those counters after call establishment and handover
Change-Id: Ib073b097a840ca3a8ee99c4ed41f59f574191d98
Related: OS#3292
as_media() tests both, IPACC/RSL media handling and MGCP media
handling. These two domains are technically quite separate, which
means we can split them up into two separate altsteps in order
to increase readability of the code.
- Split as_media() into as_Media_ipacc() and as_Media_mgw()
Change-Id: I539e8ffdb9f99d5a8e730dd918df502614b9e84d
Related: OS#3292
since the local MGW may not support transcoding, osmo-bsc should
avoid to LCLS call legs that use different codec/rate. This test
attemts to set up a call with different codec rate and checks if
those legs do not get LCLSed
Change-Id: I91b132306e530ad9ca03fb4a34012381be6b0b52
Depends: osmo-bsc I157549129a40c64364dc126f67195759e5f1d60f
Related: OS#1602
At the moment LCLS is only tested using GSM-FR. There are not LCLS
tests that test with GSM-HR yet. Lets make GSM-HR available and see
what happens when we run BSC_Tests_LCLS.TC_lcls_gcr_bway_connect
on HR instead of FR.
- set channelType depending on g_pars.ass_codec_list.codecElements[0]
- add testcase TC_lcls_gcr_bway_connect_hr
Related OS#1602
Change-Id: I2421519a642bdb7453ae4a9058e177845690a489
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
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
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
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
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
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
When f_ass_patch_lcls() was recently introduced during LCLS support
patches, we broke any testcases that *expected* an ASSIGNMENT FAIL
by overwriting the ASSIGNMENT FAIL with an ASSIGNMENT COMPL.
This patch fixes f_ass_patch_lcls() to only patch 'assignmentComplete'
members, if this assignmentComplete is actually chosen.
This fixes BSC_Tests.TC_assignment_fr_a5_1_codec_missing
Change-Id: I64fbf4cc3178a91913143960475a0d3758779ced
This is an early WIP, we actually will need to establish two calls/legs
before the BSC is able to locally correlate them.
Related: OS#1602
Change-Id: Ie6d0b9c38027abf65c7c564fc79b889d013fa6a7
In case we want to derive other component types by extending
MSC_ConnectionHandler, we will want to connect additional ports
before starting the component.
Hence, split the connect part into f_create_handler(), while keeping
the create + start part in f_start_handler().
Change-Id: If272816b7e720e8b8f000f7ab8baa20619b35fb7
Two paging tests were failing in Jenkins due to a configuration problem.
This has now been fixed so we can expect these two tests to pass:
TC_paging_imsi_nochan_lac
TC_paging_imsi_nochan_lai
Related: g#9361
Related: docker-playground 4147adabb9917fd852cc49c93603f379ec810c6b
Change-Id: I1a3dc5fb13385549bb9ec523271a5da5dc6aaa8c
The osmo-bsc.cfg file in docker-playground/ttcn3-bsc-test contains
codec, encryption, and ipaccess settings which were missing from
the corresponding configuration file in this repository. This caused
spurious test failures when running BSC_Tests outside of Jenkins.
Change-Id: If392dcd42fb741c7ab8ae204bbefde89f05f0afe
The helper function f_tc_ciph_mode_a5(), thich performs all of the
three tests currently disables the ASSIGNMENT COMMAND since due to
a bug in OsmoBSC a MODE MODIFY would be attempted by the BSC,
causing the testcase to fail.
The problem in OsmoBSC is now fixed and the ASSIGNMENT COMMAND can
be re-enabled again for this test. However, the test function
includes and expects an AoIP transport layer address, which is
not included for signalling assignments.
- Make sure no AoIP transport identifier is included in ths
ASSIGNMENT COMMAND
- Do not expect an AoIP transport identifier in the
ASSIGNMENT COMPLETE from the BSC
- Re-Enable the generation of the ASSIGNMENT COMMAND
Change-Id: Ib39d7dd2d1b3665570d7b287e431d10111316437
Closes: OS#2936
The helper function f_establish_fully() checks the channel type
for compatibility. If the channel type is compatible with the
desired mode a channel mode modification could be necessary if
the current channel mode is different from the desired channel
mode. However, this is not checked at the momemend. We just
blindly expect a MODE MODIFY message from the BSC and ignore
the cases where the current channel mode and the desired channel
mode already matches up. This is the case if only a signalling
channel is requested with f_establish_fully for example.
- Check if the channel mode of the current channel and the
desired channel mode match up.
- Make sure that the MODE MODIFY from the BSC is only
expected when the channel modes are different.
Note: The function f_channel_needs_modify() that is used
to determine if a channel modification is needed or not
does not cover all cases yet. (see fixme note)
Change-Id: I9004f299220b01ecea6b2316ba3f913c316947dc
Closes: OS#2762
Related: OS#2936
In non-handler mode, the SCCP emulation is currently started before
there's a user registered to SCCP_SP_PORT. If the first BSSMAP
package arrives from the network, then the SCCP_Emulation will crash
as it cannot deliver the resulting SCCP user primitive to the user.
Let's split start from initialization, so user code can still register
something to SCCP_SP_PORT before starting SCCP_Emulation.
Change-Id: I55c94f18531bb7e5369500dc90f4b0ff3a420774
In SCCPlite, the codec list is always missing, and that's the
successful situation, not a failure case. Let's run this test
only in AoIP scenarios.
Related: OS#2544
Change-Id: I01db7628c2b1c58419d544fc6fa311b9d9b59fb9
Neels Hofmeyr
Daniel Willmann
Neels Hofmeyr
Philipp Maier
Pau Espin
Harald Welte