These tests were expecting two ClearCommands, but the MSC will
only send one. Remove redundant calls to f_expect_clear() outside
of the alt step. The expected ClearCommand is received inside the
alt step.
Change-Id: I77f189d9050a06fe6eac457312285cf173c842d5
The NS_Emulation has configuration values hardcoded or bound
to module parameters which prevents multiple instances.
Replace the module parameter based configuration with configuration
given when starting the NS_Emaulation.
Change-Id: I9128f9ad5c372779c38799269393137ba52576cd
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
Add tests TC_tch_sign_l2_fill_frame and TC_tch_sign_l2_fill_frame_dtxd.
TC_tch_sign_l2_fill_frame is already passing and verifies that fill
frames are sent if there is nothing else to transmit on a SDCCH4/SDCCH8,
TCH/H, or TCH/F signalling channel where DTX is disabled for downlink.
TC_tch_sign_l2_fill_frame_dtxd is currently failing. It verifies that
only specific fill frames are sent, as required by GSM 05.08 for TCHF
signalling channels with DTX enabled for downlink. At present, our
implementation generates no fill frames in this case, which is one
piece of the problem described in issue OS#1950.
Change-Id: Id4e0de6e78b62cd408f600a57a28617d91da64af
Related: OS#1950
As OsmoHLR is getting support for external USSD Entities (EUSEs),
we have to implement this function in the test logic in order to
test it.
Change-Id: Ibab210b06abfd5a21e81c7f7fbe574c4f67414a0
This function starts the SCCP component which will relay the BSSAP
messages to/from port SCCP_SP_PORT which is connected to BSSAP_DIRECT.
Ticket: OS#3286
Change-Id: Icee085d5fe610061c85d7fe7cf62cbccd8cfa556
TC_two_crcx_and_one_mdcx_rtp_ho sometimes failed while trying to send an
RTP packet without a connected port. f_flow_modify re-bind()s the port,
sends the MDCX and then connect()s it after the MDCX ACK returned the
IP/port combination.
If the transmit timer fires off between the bind and connect the
resulting send call will fail.
Change-Id: Idf93ceb830a44dafa56430ab5178f05da6bdd6fb
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
The idea of this test case is to check the reaction of OsmoMSC
on MS-initiated release during an active transaction. In other
words, when the network is waiting for some response from a MS,
subscriber can press the 'red button' in order to terminate
this conversation.
It is expected that the MSC would terminate the transaction
as on DTAP interface, as on GSUP interface.
Change-Id: I7936ed5072ed2ae02f039dc90a1fece1e7f70a70
This change introduces two new test cases for network-initiaded
USSD notification and network-initiaded USSD request, which are
based on the existing SS/USSD related test cases.
The idea of TC_lu_and_mt_ussd_notification is to verify that
a network-initiaded USSD notification can arrive subscriber in
IDLE mode using Paging procedure.
The idea of TC_lu_and_mt_ussd_during_mt_call is to verify that
a network-initiaded USSD notification can arrive subscriber in
DEDICATED mode (in this case during a call) on a separate
transaction.
Change-Id: I073893c6e11be27e9e36f98f11c1491d0c173985
As we are about to finish the implementation of GSM TS 09.11,
OsmoMSC will forward all SS/USSD messages over GSUP to HLR,
and will expect responses back from HLR. The SS/USSD payload
processing will be out of scope for OsmoMSC itself.
Let's modify the existing test cases in order to expect and
reply SS/USSD messages over GSUP protocol.
Change-Id: I01de73aced6057328a121577a5a83bc2615fb2d4
In order to avoid code duplication in the upcoming test cases,
let's introduce a few functions which basically do a GSUP/DTAP
message matching within the alternative statement.
Change-Id: I846c2d40a7c37afa8647e644673b4df905e3e116
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
Due to OS#3418, both encryption and RLL tests have been failing.
It's time to enable Bm (TCH/F FACCH) channel related tests now!
Please note that Lm (TCH/H) remains disabled because of OS#3419.
Change-Id: I7c0f9f9f695e089e4a30f63ec362d1e6c18abff0
Related: OS#3256
Thanks to Stefan Sperling, a critical bug was discovered in trxcon.
The problem was that length of LAPDm frames was not checked before
passing them to the libosmocoding API. So, if a received LAPDm
frame is shorter than expected (i.e. 23 bytes), then:
- in case of xCCH, there was a heap overflow (detected by ASAN),
so a short frame has been encoded together with some garbage
outside the primitive buffer...
- in case of FACCH, as the length != 23, a frame was recognised
as a speech frame, and also encoded together with some garbage.
Since the bug is fixed (OS#3415), some TTCN-3 BTS tests started
to fail, because most likely it was assumed that trxcon would
pad the frames automatically, but it doesn't and shouldn't.
Let's automatically pad LAPDm frames with 0x2b before sending.
Change-Id: I16cba4e4179456bebabf0638760af011a27fd333
Related: OS#3418
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
This test has been passing since osmo-bts commit
eee7247ebe0d0a54a54b53b739bdd434dfceb511, so expect
it to pass instead of fail.
Change-Id: I576f881fcb40c4fcbe6b6f767220111a0e9ffd3c
Related: OS#3173
The random length for that test could go out of bounds leading to a
Dynamic test case error when sending the message.
The limiting field here is the lengthIndicator of PDU_BSSAP which
includes the length of the PDU_BSSMAP mesageType, cellId as well as the
layer3 info IE and lenght indicator additionally to the l3info payload.
So maximum length for the payload can only be 240 bytes (if the cell ID
is encoded in the longest possible way as BSSMAP_FIELD_LAC_RNC_CI).
Change-Id: I7be33e261a11f03a80a6b770b6acf0a4be49b85b
This is the bts version of patch 637ef6c8
Again I picked a test that sometimes failed -
BTS_Tests.TC_sacch_info_mod - and ran it 20 times before and after this
commit. Before it failed roughly half the time with a DTE and after I
was not able to make it fail.
Change-Id: I96f02037283b79a93ef4d659b00a90ac519c0a75
It is legal that two connections use the same codec but negotiate
different dynamic payload types for both connections. Then the MGW is
expected to receive packets with one PT and send them with the other PT.
This is currently not done in osmo-mgw so the two tests that this commit
adds are expected to fail for now.
- add testcase TC_two_crcx_diff_pt_and_rtp
- add testcase TC_two_crcx_diff_pt_and_rtp_bidir
Change-Id: Ib4606dfc08764410ee9e450949361544adb07cd3
Related: OS#3384
At the moment we check the error counters of the RTP statistics in
the testcases. However, in most situations we will do the check to
make sure that no errors occurred (all counters == 0). Rather than
having a long tail of if statements in the testcases we should have
a function for this. This also makes it much easier in case we add
more error countes lateron.
- add and use function f_rtpem_stats_err_check()
Change-Id: I69e5f80b0765284ec99056ce62c315461967d2a1
Related: OS#3384
Because trxcon now requires frames of a minimum size some
BTS tests which send unpadded frames with a short payload
have started to fail.
Extend the payload size generated by f_TC_rll_ud_ind()
to make TC_rll_unit_data_ind_DCCH pass again.
Change-Id: Ibaa4124ebdec96623f48c38fac702e9bbd843869
Related: OS#3415
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
Since trxcon now drops L2 frames of an incorrect length, some
BTS tests which send unpadded frames with a short payload
have started to fail.
Extend the payload size generated by f_TC_chan_act_encr()
to make these tests pass again:
TC_chan_act_a51
TC_chan_act_a52
TC_chan_act_a53
Found by: Vadim Yanitskiy
Related: OS#3415
Change-Id: I0f9a40503a4ed4fce10d9655f845ac49d33f4041
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
When an RTP packet is received, the payload type is not checked,
so we will not detect if the MGW emits packets with a wrong payload
type for some reason.
- Introduce a statistics counter that counts packets with wrong PT
- Update testcases so that they check for the statistics for wrong
PT count.
Change-Id: I83d4b04656a16ced624024245a2fcb7a0ad48a8a
Related: OS#3384
BSC_ConnectionHandler.ttcn:563 This helps TC_gsup_cancel which
previously encountered a Dynamic test case error: Using the value of an
optional field containing omit. The test still fails, but this time
because it "Received unexpected BSSAP instead of CM SERV REJ".
Change-Id: I9fedf2573487066b951804a328ba428d2189c4a4
Call mtc.stop after setverdict(fail), add reasons to most failures and
fail with verdict error for internal errors.
Change-Id: I9b618235939fa41160b9be6677b121963d3ec857
This will prevent subsequent failures from overwriting the verdict so we
can easily see the root cause of the test failure.
Using testcase.stop instead for errors internal to our test
infrastructure to mark them as test errors instead of failed.
Change-Id: Idc6819aaf0b01e70c38fad828dd44dcec6bdd778
It's not needed for the functionality/scenario of f_gtpu_xceive_mo. It
probably was left in when creating it from f_gtpu_xceive_mo.
Change-Id: Ide226f8501c4598e2bfaa5f1ea62c3ff20807ce4
At the moment the RTP stream emulation is left in its default
configuration, this means that the payload type that appears in the RTP
stream is always 0. This may mismatch the payload type that is
configured with MGCP.
If nothing else is set, we should make sure that whan we create and modify
flows, the RTP emulation is always reconfigured to use the payload-type that
we set in the flow parameters. The other rtp-emulation parameters should
be set to their defaults.
- Make sure f_flow_modify and f_flow_create set the rtp flow parameters
properly.
Change-Id: Ie888424ac3e0bf0d960b6f071855b6dd43935a0e
Related:OS#3384
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 test currently crashes osmo-msc, which is fixed by
I5c30e0f9545fb76615776ff6cc16b56aeb5b043a (osmo-msc).
Related: OS#3062
Change-Id: Ic80646e1fba37bb6163ca3a7eead7980b4ad7a51
Alexander Couzens
Daniel Willmann
Harald Welte
Neels Hofmeyr
Philipp Maier
Pau Espin