summaryrefslogtreecommitdiffstats
path: root/bsc/BSC_Tests.ttcn
AgeCommit message (Collapse)AuthorFilesLines
2019-03-27BSC_Tests: execute S15-S0 related tests only on AoIPPhilipp Maier1-17/+20
Make sure that the S15-S0 related testcases are only executed when AoIP is used as transport. Change-Id: I62d51bbe4b1f089ded6c271b68414a4a37d509d8 Related: OS#3864
2019-03-19BSC_Tests: add testcases to verify S15-S0 handlingPhilipp Maier1-0/+222
The handling of the AMR rate configuration bits S15-S0 is currently only superficially checked. Lets add more some more elaborated testcases to check through varios different situations. Also make sure that the resulting mr configuration IE is verified Change-Id: Ica323deb9836deea72982e093c9cb31deb5a216b Related: SYS#4470
2019-03-19BSC_Tests: fix TC_assignment_codec_amr_f/hPhilipp Maier1-2/+2
The testcase TC_assignment_codec_amr_f uses a combination of S-Bits that has S1 which configures a set of four rates at once. This is quite a complex situation and since the BSC was upgraded with new features affecting the behavior in this special case lets simplify this testcase for now. depends: osmo-bsc Ie52376b51fe07ed07056e8df2e9557293ff67a78 Change-Id: Ibf730f76947cdeed23eb3119167450e3b7a9b314 Related: SYS#4470
2019-02-05bsc: Test CSFB "Fast Return" in new TC_chan_rel_hard_clear_csfbHarald Welte1-2/+31
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
2019-02-05bsc: replace octet string with decmatch when matching RR RELEASEHarald Welte1-3/+2
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
2019-02-05BSC_Tests: Don't make invalid assumptions about RR RELEASEHarald Welte1-4/+3
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
2019-01-29BSC_Tests: fix vty interface for channel allocator testsPhilipp Maier1-12/+12
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
2019-01-29BSC_Tests: Add tests to check channel allocatorPhilipp Maier1-0/+294
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
2018-12-10bsc: TC_chan_exhaustion: Send correct RA to alloc all different channelsPau Espin Pedrol1-2/+4
Previous RA value (23, Establishment cause = 0010XXXX) meant MS was dual rate capable but was asking speciifically for only TCH/F channel. As a result, TCH/H was not being allocated and an immediate assignment reject was sent. Change-Id: I3e58592c661fc004e648dbe46b67a3b3f5a20bc8
2018-12-08BSC_Tests: expect a HANDOVER PERFORMED message on internal handoverPhilipp Maier1-0/+4
When an internal handover is performed, the BSC is expected to inform the MSC about the event by sending a BSSMAP HANDOVER PERFORMED message. This feature was missing in the BSC and has now been added. The tests need to be upgraded in order to handle the additional message. - Upgrade f_tc_ho_int so that it expects a HANDOVER PERFORMED message Change-Id: I10f4e578c96a90317939ba49b61b14a3c7e488a7 Depends: osmo-bsc If26e5807280e0f75a423b3b04f8e3c698c82a351 Related: OS#3645
2018-12-07bsc: Fix TC_paging_resp_unsolPau Espin Pedrol1-1/+1
TC_paging_resp_unsol spent some time in gerrit before being merged. As a result, other commits were merged in between the test was submitted (tested) and merged. As a result, commit a5302c8151d1da2e43ed52efc0544d70bffab911 was merged while this test was still in gerrit and thus was not updated accordingly. Similar stuff happened with the osmo-bsc commit fixing the scenario this test was showcasing: The osmo-bsc patch (77cd1129931928d2a6e7667d0374feeeed71b0ce) had merge conflict with other osmo-bsc commits merged in-between, and was merged even later than the commit introducing this TTCN3 test, so failures were expected for this test for a while. Change-Id: I933cba41912640eb7e15be4a27bda5b4dd489962
2018-11-27bsc: Start the timer at the beginning of f_initDaniel Willmann1-2/+3
This avoids a possible indefinite timeout if osmo-bsc crashes during the test. Ticket: OS#3713 Change-Id: I88f6254d9d2d90ab49a3c3d8255af25ca6ffe624
2018-11-27BSC_Tests.ttcn: introduce TC_chan_deact_silenceVadim Yanitskiy1-0/+34
The idea of this test case is to verify channel deactivation procedure due to no response to Immediate Assignment. Change-Id: I00b0838c9f919303aef72280248b0d1317f42b3b Related: OS#3709
2018-11-22bsc: Introduce test TC_paging_resp_unsolPau Espin Pedrol1-0/+25
With this test we want to verify that channels are released if BSC fails to complete an L3 request, for instance because no pending Paging CMD is found for a received Paging Response. Related: OS#3680 Change-Id: Iabe8a51aa13d2fcfec4500cf7aab47d60cc138ce
2018-11-19bsc: add inter-bsc ho incoming failure testsNeels Hofmeyr1-0/+348
Change-Id: I849e4c0a14cc091195d948adb8df7a0b7414ecfe
2018-11-19BSC: log BTS number on failureMax1-1/+1
It's useful to see which BTS exactly has failed the test in configuration with multiple BTS on single BSC. Change-Id: Ib813635862c04d51a30e7bbcca4ec05ce664f7e9
2018-11-19BSC LCLS: add bts-loop testsMax1-1/+1
Add basic establishment and teardown tests for 'bts-loop' mode of LCLS: * add explicit vty init for desired LCLS kind * add necessary IPA RSL MDCX functions * explicitly pass LCLS kind as a parameter to shared functions (defaulting to 'mgw-loop') Change-Id: I40e786b430591899c722d99d685db26efa868508 Related: OS#3659
2018-11-15attempt to fix a race condition in BSC test's f_ts_dyn_mode_getStefan Sperling1-2/+1
Add two helper functions which retry a VTY command until the result matches a regular expression or a configurable timeout expires. Use these functions in BSC test's f_ts_dyn_mode_get, which has seen sporadic failures due to a race condition during channel reconfiguration, in order to hopefully close this race. Change-Id: I308ddb06e440c165fe1e73fe2c1fb78be2e1d510 Related: OS#3690
2018-11-14bsc: check channel release message presenceNeels Hofmeyr1-17/+36
Instead of vaguely allowing any release messages to be present or not, exactly pinpoint for each test case the exact release messages expected during lchan release. Related: an osmo-bsc change broke sending of RR Release messages, which was utterly ignored and hence not caught by ttcn tests. That must not happen again. I am not actually sure that these expectations are 100% correct; if errors become apparent, we shall change the expectations in ttcn3 and then fix osmo-bsc according to that. Adjust f_expect_chan_rel() and callers, and the Assignment procedures (as_assignment and f_establish_fully). The current state of the bsc tests should all pass with osmo-bsc Id3301df059582da2377ef82feae554e94fa42035 Related: OS#3413 Change-Id: Ibc64058f1e214bea585f4e8dcb66f3df8ead3845
2018-11-14bsc: handle Deact SACCH messagesNeels Hofmeyr1-0/+4
Allow osmo-bsc sending a Deact SACCH messages in most cases. Prepare the ttcn3-bsc-tests to not break just because of those messages that will soon be sent. When releasing an lchan, it makes sense to Deactivate SACCH on it, if it was ever active. So far osmo-bsc was fairly reluctant to send Deactivate SACCH, but osmo-bsc Id3301df059582da2377ef82feae554e94fa42035 is about to change that. In most test cases, Deact SACCH are still optional, but in one case, the current missing Deact SACCH will introduce a test failure: in the 'interleave' of BSC_Tests.TC_ho_out_fail_no_ho_detect. As soon as abovementioned osmo-bsc patch is merged, the test will pass again. Also, as soon as Ibc64058f1e214bea585f4e8dcb66f3df8ead3845 is merged here, the bsc tests will properly ensure whether Deact SACCH is sent or not in all tests. Change-Id: I27da24dbe3184fa7a076a35f6fa6af457c1db8d2
2018-11-14bsc: handle RR Release messagesNeels Hofmeyr1-0/+8
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
2018-11-14bsc: TC_chan_act_ack_est_ind_noreply: use f_expect_chan_relNeels Hofmeyr1-9/+1
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
2018-11-14bsc: remove flush from f_expect_chan_relNeels Hofmeyr1-7/+3
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
2018-11-06cosmetic: fix typosMax1-1/+1
Change-Id: I6e75af46e134d33f752214988054105aba91366c
2018-10-29bsc: Use f_gen_test_hdlr_pars() to be aware of AoIP/sccpliteDaniel Willmann1-3/+3
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
2018-10-15add an IPA test which sends a chopped payloadStefan Sperling1-0/+10
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
2018-10-15run TC_chopped_ipa_ping on BSC ctrl interfaceStefan Sperling1-3/+1
With a related patch to libosmocore, this test will pass on osmo-bsc's ctrl interface. Change-Id: I20a4f251dbe3e75a5c53a0ff167998bbd1266f62 Depends: I9d7137c830981ccad03806b30b776e2b1f1b4699 Related: OS#2010
2018-10-11bsc: add 3 tests for inter-BSC HO outgoing failuresNeels Hofmeyr1-0/+211
Add * TC_ho_out_fail_no_msc_response() * TC_ho_out_fail_rr_ho_failure() * TC_ho_out_fail_no_ho_detect() Depends: I0980cacb9713e41a1eef3a0a7f6cc892e8a20da5 (osmo-bsc) Change-Id: If772dbbc5f9790d3f911465e1303dd0a99811154
2018-10-10MSC_ConnectionHandler: Use explicit AoIP flagPhilipp Maier1-22/+34
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
2018-10-09document why ipa chopped ping fails with control interfaceStefan Sperling1-2/+3
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
2018-10-08Add a TTCN3 module for IPA protocol testingStefan Sperling1-0/+11
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
2018-10-05BSC_Tests: use consistant AMR S0-S15 bitsPhilipp Maier1-4/+16
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
2018-09-28Revert "BSC_Tests: use consistant AMR S0-S15 bits"Philipp Maier1-16/+4
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 7f5609ad3e65098cca3d79565a1aa80460c49bed. Change-Id: Ib16d14c723773ce67508c7e6028e594c15779506
2018-09-26bsc: inter-BSC HO: add TC_ho_out_of_this_bsc, TC_ho_into_this_bscNeels Hofmeyr1-0/+177
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
2018-09-21BSC_Tests: use consistant AMR S0-S15 bitsPhilipp Maier1-4/+16
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
2018-09-18bsc: test Classmark EnquiryNeels Hofmeyr1-1/+6
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
2018-08-22log / comment tweaksNeels Hofmeyr1-1/+11
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
2018-08-10bsc: Wait for immedate assignment in f_chreq_act_ackDaniel Willmann1-0/+1
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
2018-07-31BSC_Tests: Avoid race condition between paging cmd and reset ackDaniel Willmann1-0/+4
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
2018-07-25bsc: stop all components before terminating testcaseDaniel Willmann1-0/+1
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
2018-07-24introduce a TTCN3 test suite for SCCPStefan Sperling1-0/+1
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
2018-07-24Stop tests after failuresDaniel Willmann1-25/+18
Call mtc.stop after setverdict(fail), add reasons to most failures and fail with verdict error for internal errors. Change-Id: I9b618235939fa41160b9be6677b121963d3ec857
2018-07-11BSC_Tests: count MGCP operations in as_mediaPhilipp Maier1-1/+10
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
2018-07-09BSC_Tests: Also test LCLS with halfrate codecsPhilipp Maier1-1/+1
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
2018-07-04bsc: verify MultiRate Config IE in RSL Chan ActivNeels Hofmeyr1-0/+34
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
2018-06-27bsc: fix TC_{early,late}_conn_fail: dyn PDCH: clean up cfgNeels Hofmeyr1-0/+12
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
2018-06-16bsc: fix TC_chan_rel_hard_rlsd_ms_dead: ignore RLL RELNeels Hofmeyr1-0/+5
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
2018-06-14bsc: Add TC_{early,late}_conn_fail()Harald Welte1-0/+61
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
2018-06-14bsc: Factor out duplicated code into f_exp_chan_rel_and_clear()Harald Welte1-40/+19
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
2018-06-11bsc: Add TC_chan_rel_hard_rlsd_ms_deadHarald Welte1-0/+16
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