Receive RR Release messages if they happen during lchan release. Add RR Release
to the alt{}s in both f_expect_chan_rel() to cover a whole bunch of test cases,
and in f_tc_ho_out_fail_no_ho_detect() which has its own release expectations.
Before this, RR Release messages would typically be lost in the RSL.clear
recently removed by Ie1be30c3f109dda8c58c523df508211f8e20aad3.
However, I still expect tests to pass after this, since the current osmo-bsc
master has a bug that omits RR Release messages (since [1]).
By applying this patch, both the buggy osmo-bsc (omitting RR Release) and the
fix of that [2] should pass the BSC tests. So far by accepting whatever comes
along, and not complaining if it doesn't come along.
A subsequent patch will more precisely ensure that exactly the expected
messages will be sent by osmo-bsc (Ibc64058f1e214bea585f4e8dcb66f3df8ead3845).
[1] osmo-bsc I4fd582b41ba4599af704d670af83651d2450b1db
commit 8b818a01b00ea3daad4ad58c162ac52b4f08a5cb
"subscr conn: properly forget lchan before release"
[2] osmo-bsc I666b3b4f45706d898d664d380bd0fd2b018be358
"fix: send RR Release (e.g. after BSSMAP Clear Cmd"
Related: OS#3413
Change-Id: I4e6d266d091b140f56b28312cb3c5d67ffcc3a59
Instead of placing an own set of channel release expectations, just use the
common f_expect_chan_rel() that exists for exactly this purpose.
This will also be in line with upcoming changes to tighten checking of the
lchan release messages.
Related: OS#3413
Change-Id: Ib7dd886472337e2deb968e6f9de6cecdb7855319
When we're expecting release, it can be non-deterministic / timing dependent to
flush the RSL queue. Particularly the RR Release message is typically already
in the queue when f_expect_chan_rel() is called and would be lost.
It turns out that none of the current callers need the flush feature.
If a test needs it, we can add a separate f_rsl_flush() function and call that,
no need to clutter up the f_expect_chan_rel() argument list. I had such
function but found that no caller needs it, so dropped it.
Related: OS#3413
Change-Id: Ie1be30c3f109dda8c58c523df508211f8e20aad3
Check that channel number IE is present in the received message. This
fixes following warning:
The value returned by function `@RSL_Types.f_rsl_find_ie' is not used
Change-Id: Icc6824d7acef809d76c70b5ff060a8261a82e2be
Related: OS#3659
The osmo-bsc.cfg should work on localhost. Having arbitrary IP address
in it seems confusing and might lead to hard-to-debug errors.
Change-Id: Ideb8a78348af435f9992c42bce0bb197d1e73e04
Unfortunately all component.stop can not be called from the non-mtc
component. f_shutdown is a wrapper that will try to shutdown a test in
the best way calling all component.stop if it is called from the mtc and
just stopping the mtc if called from any other component.
Change-Id: I9b71f7f7bd70d2da21fbad60c340d5bf8b3b9536
Some TC_no_out_fail_* testcases still used valueof() to get g_pars which
always set aoip to true.
Use f_gen_test_hdlr_pars() now so these tests can properly detect if
they are run with sccplite of aoip and can adjust their expectations
accordingly.
Change-Id: Ic164827d63c9f5452888951bba4c197c3fe6f57b
This function can now be called from anywhere to try and safely shutdown
a testcase. It is not optimal as we can't call "all component.stop" from
outside the mtc, but without any proper and orderly shutdown handling of
all our emulation components I believe this is the best we can do.
To use it:
import from Misc_Helpers all;
in your module and then call
Misc_Helpers.f_shutdown(__BFILE__, __LINE__);
You can also pass the function a verdict and a message and it will take care
of calling setverdict, but beware of the following:
While setverdict would accept any number of arguments as log message
and convert them to a log string f_shutdown expects one charstring.
It's possible to use the log2str function to use the log arguments in
setverdict for f_shutdown, for example
setverdict(fail, "Template didn't match: ", tmpl_foo);
would become
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, log2str("Template didn't match: ", tmpl_foo));
Change-Id: I84d1aa6732f6b748d2bfdeac8f6309023717f267
Add another IPA test to the BTS and BSC test suites.
This new test sends the header in one burst, followed by the
payload which is transmitted byte-per-byte.
The test uses an ID REQ message. If acting as a server, the test
can expect an ID RESP message. However, if acting as a client, the
server will close the connection when it receives the ID REQ.
The CTRL interface port on the BSC does not close the connection in
this case, so that particular port is skipped by the test for now.
Change-Id: If75cb90841bb25619b414f0cabe008a2428a9fdf
Related: OS#2010
Depends: I4804ccabd342b82d44e69dbc6eaaae220ec7d4e4
With a related patch to libosmocore, this test will pass on
osmo-bsc's ctrl interface.
Change-Id: I20a4f251dbe3e75a5c53a0ff167998bbd1266f62
Depends: I9d7137c830981ccad03806b30b776e2b1f1b4699
Related: OS#2010
Most differences between sccplite and AoIP are visible during the
assignment. The current implementation checks for the presence of a CIC
in the ASSIGNMENT REQUEST in order to detect if the communication should
be modeled by AoIP or sccplite. This method is error prone and does not
work very well in situations where only signalling is used, because
there in sccplite and AoIP no CIC or AoIP trasp. identifier is present,
so there is nothing to check on. To resolve this we need an explicit way
to tell the MSC_ConnectionHandler that it has to behave like an AoIP MSC
or like an sccplite MSC.
- Add an aoip flag to TestHdlrParams
- Make sure BSC_Tests.ttcn sets the AoIP depending on mp_bssap_cfg.transport
Change-Id: I800249e783deb018d99e81d814843e0574a5c69b
Related: OS#3639
We cannot test the control interface with an IPA ping message.
The control interface only supports osmocom-specific extensions,
and the IPA ping message is not part of those extensions.
Other tests will have to be devised for the control interface.
Change-Id: Iae0f16394c78196de621c14b34d1b1905c0cb7c8
Related: OS#2010
This new module allows us to test IPA code in libosmocore
and libosmo-netif. Currently only one test is implemented,
which sends a chopped IPA ping message and expects to receive
an IPA pong.
The system under test is any IPA speaker on any TCP port.
Any test suite may call parametrized functions to create
an IPA testing component and run a particular test.
So far, one such test has been added to the BSC_Tests suite.
Change-Id: I246a405414e36a44dc1e308692faab8bf04da0e6
Related: OS#2010
Since our BSC implementation supports AoIP, the COMPLETE LAYER 3
INFORMATION message must contan a Codec List (BSS Supported) information
element. The test currently just receive a L3 compl Template and then
continue. This is implemented without an altstep. So lets have an altstep
with timeout here and make sure that the codecList information element is
always included.
However, since AoIP was specified after sccp-lite, we need to make sure
that for sccp-lite configurations, the Codec List is not included.
- Check L3 compl message using an alt-step
- Make sure codecList is always included (for AoIP)
Change-Id: Ia16a454e78421430ec32cc37939d429970cb06ec
Related: OS#3548
At the moment we use the default S0-S15 bits for the AMR config,
regardless what RSL_IE_Body mr_conf or osmo-bsc.cfg sets.
- Make sure consistant S0-S15 bits are used for AMR related tests.
This is a re-submit of change I794e6d4fe8abc67337428cbe0bcc8802fae37a6e,
which had to be reverted because the depending patch in osmo-bsc is not
yet merged into master. This caused TC_assignment_codec_amr_f and
TC_assignment_codec_amr_h to fail.
Change-Id: Ia98f18ba2c17c85ed01488734dc6df67f5b60d41
Depends: osmo-bsc: I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737
Related: OS#3529
The change depends on another change in osmo-bsc, which
is not in master yet. Because of this TC_assignment_codec_amr_f
and TC_assignment_codec_amr_h are currently failing. So lets
revert this patch and re-submit it later.
See also: osmo-bsc change I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737
This reverts commit 7f5609ad3e.
Change-Id: Ib16d14c723773ce67508c7e6028e594c15779506
Add f_gen_handover_req() like f_gen_ass_req(), to match AoIP or SCCPlite
requirements.
For incoming HO, MSC_ConnHdlr needs to know the SCCP addresses to expect the
incoming SCCP Connection from MSC to BSC. Add 'handover' section to
TestHdlrParams, and pass in the addresses from test_CT via that.
In osmo-bsc.cfg, add a remote neighbor config, so that the VTY command
'handover any to arfcn 123 bsic any' can trigger an outgoing inter-BSC HO.
Add various BSSMAP handover templates to BSSMAP_Templates.ttcn.
Add RR Ho Command template to L3_Templates.ttcn.
Move ts_BSSAP_Conn_Req() from msc/BSC_ConnectionHandler.ttcn to
library/BSSMAP_Emulation.ttcn, so we can also model an SCCP Connection Request
in BSC_Tests.ttcn (this time from MSC to BSC).
Add the two new tests to bsc/expected-results.xml.
Related: OS#2283
Change-Id: Id22852d4be7f127d827e7a8beeec55db27c07f03
At the moment we use the default S0-S15 bits for the AMR config,
regardless what RSL_IE_Body mr_conf or osmo-bsc.cfg sets.
- Make sure consistant S0-S15 bits are used for AMR related tests.
Change-Id: I794e6d4fe8abc67337428cbe0bcc8802fae37a6e
Enhance TC_classmark to also include the BSSMAP Classmark Request -> RR
Classmark Enquiry part. So far it was only testing the return path of RR
Classmark Change -> BSSMAP Classmark Update.
This test will thus fail with current osmo-bsc master, and will succeed as soon
as osmo-bsc If5db638fd6e8d9c2ef9e139e99f0fabe1ef16ddf is merged.
Add:
* ts_BSSMAP_ClassmarkRequest in BSSMAP_Templates.ttcn
* tr_RRM_CM_ENQUIRY in L3_Templates.ttcn
Change-Id: Idaab4d568cf986b4897ba008f6262c839d1592fb
When the altstep in f_establish_fully() gets an unexpected ASSIGNMENT
FAIL or COMPLETE it should stop completely like it is already
implemented in many other altsteps.
Change-Id: Ib4ac7bcbac35a4ae454d1806f3fbb727834d18b7
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
Neels Hofmeyr
Daniel Willmann
Philipp Maier
Harald Welte
Neels Hofmeyr
Pau Espin