I found some of the tests hard to analyse when geting failures, because they
don't stop the test on failure. Spread some 'mtc.stop' so that the test stops
at the failed message instead of carrying on.
Change-Id: I804aca84d0ccf4767a5c097cf6c882ccbd87c4e1
Ideally some more checks should be done on this test at the end, but
it's fine keeping it as it is for now and can be extended later.
Change-Id: I3be5123ff5294e5851652ec14d54589442082b28
The scenario in this test triggers a crash in osmo-sgsn fixed by
osmo-sgsn.git I64fa5cf1b427d3abb99e553e584897261a827ce6.
With that osmo-sgsn patch applied, the process doesn't crash anymore but
the test still fails due to an XID message being sent with a new
yet-not-seen-by-ttcn3 TLLI and as a result TTCN3 BSSGP_Emulation fails:
BSSGP_Emulation.ttcn:390 setverdict(fail): none -> fail reason: "Couldn't find Component for TLLI 'FE791757'O", new component reason: "Couldn't find Component for TLLI 'FE791757'O"
Other than that, the test runs fine. It still needs to be clarified
whether the new TLLI sent by osmo-sgsn is expected and test needs to be
fixed, or whether it's an sgsn bug.
Related: OS#3957, OS#4245
Change-Id: Id5554a91a8bda712e282c5a3e9e30fb0ca1ec0e8
The compare-results.sh is annoyingly slow. Since our ttcn3 tests containers
support Python 2, re-implement in Python for much quicker evaluation.
Change-Id: I0747c9d66ffc7e4121497a2416fca78d7b56c8e6
Make sure that osmo-msc doesn't crash if a successful CRCX response contains an
invalid IP address.
Originally/recently, osmo-msc did not validate the IP addresses at all. In an
intermediate patch I added error handling, releasing the call. That uncovered a
use-after-free problem in libosmo-mgcp-client. This problem is fixed by
osmo_fsm_set_dealloc_ctx() and an osmo-mgw fix (see
I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 in osmo-mgw).
Add this test to make sure the crash is not re-introduced.
Change-Id: I0c76b0a7a33a96a39a242ecd387ba3769161cf7a
* Semantic:
We don't really know which side the MSC first creates a CRCX for. Instead of
assuming that the RAN side is always CRCX'd first, simply handle a "first" and
a "second" CRCX, not making any assumptions which is for which side.
Notably, there still are quite a few places assuming which CRCX corresponds to
the RAN/CN side, but the changes are sufficient to still pass the tests when
osmo-msc swaps the CRCX order; sometimes for slightly obscure reasons, for
example because it doesn't matter that the wrong port number is returned during
a subsequent MDCX... Cleaning up the rest is still todo for later.
Remove code dup from call establishing code, particularly for MGCP.
Use f_mo_call_establish() and f_mt_call() where ever possible, to make all of
the call establishing tests handle upcoming changes in osmo-msc's order of
messages, without re-implementing the changes for each test individually.
The X-Osmux parameter was so far expected to appear in the first CRCX received,
assuming that this first CRCX is for the RAN. Instead, detect whether X-Osmux
is contained in a CRCX, and reply with an Osmux CID if so, regardless of it
being the first or second CRCX. Count the number of X-Osmux parameters
received in CRCX messages, and compare after call setup to verify X-Osmux
presence.
Since f_mo_call_establish() can't handle RANAP assignment, a few Iu tests that
worked with the older code dup will break by this patch. This is fixed by a
subsequent patch, see I0ead36333ab665147b8d222070ea5cf8afc555ec.
* Details, per patch chunk:
Change ts_BSSMAP_IE_AoIP_TLA4 to a non-value template, so that we can use a
wildcard for the assigned port number from MGCP (depending on RAN or CN CRCX
first, the RAN port number can be one or the other).
In CallParameters, move MGCP handling instructions into a separate record
"CrcxResponse", and have two of them for handling the first and the second
CRCX, replacing mgw_rtp_{ip,port}_{bss,mss} and mgcp_connection_id_{bss,mss}.
In CallParameters, add some flags for early-exiting call establishment with a
particular desired behavior, for specialized tests.
In CallParameters, use common default values and don't repeat them in each and
every call establishing test.
Set cpars.mo_call := {true,false} implicitly when f_{mo,mt}_call_establish()
are invoked.
Remove CRCX comments implying RAN or CN side, instead just talk of the "first"
and the "second" CRCX.
Implement one common f_handle_crcx() function, which is used by
f_mo_call_establish(), f_mt_call_complete(), as_optional_mgcp_crcx(), and
implicitly uses the first/second CRCX handling.
For Assigment, use a wildcard RTP port so that we don't have to assume which
CRCX was for the RAN side.
In f_mo_call_establish(), insert special case conditions to make it enact
errors at specific times, for individual tests. That saves re-implementing the
entire call establishment (code dup).
For error cases, add expectation of a CC Release message in the call
establishment. This should not apply for normal successful operation, but
because interleave does not support conditionals, add flags
got_mncc_setup_compl_ind and got_cc_connect to break the interleave when
establishing is complete, so that the CC Release is skipped.
A CC Release always breaks the interleave, at whatever time it arrives.
Tests adopting f_{mo,mt}_call instead of code dup:
f_tc_mo_setup_and_nothing()
f_tc_mo_crcx_ran_timeout()
f_tc_mo_crcx_ran_reject()
f_tc_mo_release_timeout()
f_tc_mo_cc_bssmap_clear()
Change-Id: I8b82476f55a98f7a94d5c4f1cd80eac427b2d20f
SDP is added to the MNCC protocol in osmo-msc
Ie16f0804c4d99760cd4a0c544d0889b6313eebb7.
This patch adds SDP to the ttcn3 MNCC messaging.
These changes still work with current osmo-msc master that doesn't send SDP /
ignores received SDP in MNCC.
Change-Id: Ic9568c8927507e161aadfad1a4d20aa896d8ae30
Since there can be multiple PDCH channels configured on different
timeslots, different TRXes, and BTSes, the PTCCH/U handling code
in OsmoPCU needs to know the exact origin of a given RACH.ind.
Otherwise, it is not known which subscriber originated a given
PTCCH/U indication, and hence it is impossible to send PTCCH/D
Timing Advance notification properly.
Fortunately, we can extend the RACH.ind message without even
bumping the protocol version, because every single PDU has a
fixed size defined by the largest message - INFO.ind. In case
if the actual message payload is smaller, the rest is filled
with a constant padding byte (0x00).
Older versions of OsmoPCU will consider the new fields as padding,
while the messages from older OsmoBTS versions will always have
both fields set to 0x00. Since C0/TS0 cannot be configured to
PDCH, this can be easily detected on the other end.
Change-Id: Ia5c4e504a21dc5508920553d3856027455dba1b1
Related: OS#4102, OS#1545
vsmartcard.git contains an implementation of a virtual card reader
(vpcd) which registers with PC/SC (such as pcsc-lite). It simply
binds to a TCP port and waits for a TCP client to connect to it,
implementing APDU transfer over TCP.
This code implements the related protocol as a TTCN-3 test port
for Eclipse TITAN, which will enable us to implement a 'virtual smart
card' in TTCN-3 tets cases, primarily for testing remsim-bankd at
this point.
Change-Id: Iac37dd231a0f2e1efd484887bca1a9d672b446bb
As it turned out, OsmoPCU is not supposed to change the Coding
Scheme immediately when the recent link quality value leaves the
current window. Instead, in order to avoid rapid changes of the
Coding Scheme, it also takes the previous value into account.
Thus the current Coding Scheme is only changed if both current
and old values fit into a new window.
This change makes the test case pass.
Change-Id: I5d503d5a9c46cb9de84fbabd2d591afbe4216fdb
Some stuff was wrong and some was missing after new features being
implemented in tests over time.
Change-Id: I7a279592a68ffc76408a8e728e76151534265cc0
This type of scenario is used in several tests and will be used in more
tests in the future, so let's move there for easiness.
Change-Id: Ic65ff2ff9dc3cc82ae3fefcf3caf406279cd6b97
Infrastructure in STP_Tests_IPA changed to be more similar to what is
done in STP_Tests_M3UA, which already contain more advanced tests.
Array of AS names mp_ipa_as_names is added in order to let TTCN3 port
which AS is configured in STP for each src port.
Change-Id: Iae213c58598cc0207503fd10f09d2d57aab941fe
This way traffic modes set dynamically by peers are cleared and can be
reset by next tests easily.
Change-Id: I177441b2d43298b3836ccf78fe11267333e80665
In the past, we were automatically running [large parts of] the nplab
M3UA and SUA test suites, but those implement only a fraction of the
functionality. Particularly, they don't cover the non-standard IPA
behavior, and they don't cover RKM (routing key management).
Let's introduce an initial set of STP tests with this patch. We try
to not duplicate nplab here, and implement bits not covered there.
Change-Id: I628a87385cac0dfe708a0d74a5088fbd5a4790cd
We have a module parameter 'mp_l1_supports_gprs' that indicates
whether the L1 back-end (trxcon, virt_phy, or Calypso) does
support PDCH and TBF management.
The TC_pcu_ptcch does not require support of TBF management, only
PDCH (namely PTCCH) needs to be supported. This is already
implemented in trxcon, and can be easily implemented for Calypso.
Change-Id: Id2e751e825a7a5128bc3f2e4677d8ef31174b501
Otherwise most tests in bsc-latest fail because in latest release BSC
never sends that IE.
Related: OS#4244
Change-Id: I725836784a7900d2ea51eae188c2c279e8639dbf
It will allow changing ms max power in osmo-bsc.cfg as well as TTCN3
expactancies in BSC_Tests.cfg easily in docker-playground.git without
needing to recompile or change code in TTCN3.
Change-Id: Ib00c96902377582bc32778c5b947a6b4274041aa
Split f_mgcp_find_param_entry() out of f_mgcp_find_param() to be able to act on
an MgcpParameterList without an enclosing MgcpMessage.
Will be used by upcoming I8b82476f55a98f7a94d5c4f1cd80eac427b2d20f
Change-Id: I90f213d2a1be979afa024e0faa25d532f9858636
- Fix error log for a missing final DTMF.
- Instead of code dup to establish a call, use f_mo_call_establish(). This
will make the test benefit from changes to f_mo_call_establish() (which will
soon come up to accomodate changes in osmo-msc's codec negotiation).
- Instead of hardcoding the expected N_SD counter values to detect DTAP
duplicates, use f_bssmap_last_n_sd() and f_next_n_sd(), so that the N_SD
counter is correct regardless of how many DTAP were sent in
f_mo_call_establish().
- Instead of hardcoding a correct N_SD in the end, use skip_seq_patching ==
false, so that the ttcn DTAP correctly tracks N_SD for subsequent call
release messages.
- Release the call.
Change-Id: Ibfa8b906764f2d5ed75fe74125be42af4546e864
Before this, if an Assignment Request contains an unexpected Transport Layer
Address, the test completely rejects the Assignment Request.
Instead, accept any tla in the Assignment, and compare the expected tla in the
Assignment's interleave action. Thus we directly get logging hinting at the tla
instead of a T_guard timeout.
Change-Id: I04847c10d6c3bf9e04cfda6e343dfd4a65be71a5
This test case is aimed to verify handling of both PTCCH/U and
PTCCH/D logical channels, recently implemented in [1]. This is
done by sending 16 Access Bursts on PTCCH/U, and then by
sending a random data block on PTCCH/D.
The existing TC_pcu_data_req_ptcch does not cover PTCCH/U, and
moreover involves TBF handling which has nothing to do with
PTCCH. Let's keep it anyway.
[1] I232e5f514fbad2c51daaa59ff516004aba97c8a3
Change-Id: I011ffdfa63b698ce6085968d15ffb4ff4bd23ee5
Related: OS#4102
As it turns out, it was a bad idea to use a counter in altstep
as_ta_ptcch(), because its value is getting lost. Let's instead
introduce a new type PTCCH_TAI_ToA_MAP, which is basically a
list of ToA values for each PTCCH/U sub-slot (TA Index), and
pass it to the altstep.
Change-Id: I74252dfb929fcb32d07e8728d692674931fae727
Both TDMA_EV_PTCCH_DL_BLOCK and TDMA_EV_PTCCH_UL_BURST events may
happen together during the same TDMA frame (fn % 104 == 90). We
shall not skip TDMA_EV_PTCCH_UL_BURST. Let's fix this.
Change-Id: Ifc66d5d1c5f9eaa7bed6882105298c45257ebef0
Packets sent by f_gmm_attach() might take too long via layers to reach
the SGSN. The GMM_ATTACH_COMPL in f_gmm_attach() took soo long,
that it arrived after packets, which has been sent after calling f_gmm_attach().
This behaviour was found in TC hlr_location_cancel_request_update().
Change-Id: I0209c86e16fe616284d753e9e003f2e4d9ec9ea5
Test BTS_Tests.TC_dyn_osmo_pdch_act_deact was sporadically failing due
to receiving IND_INFO on the PCU port with pdch_mask related TS bit set
to 0 after sending a PDCH ACT. That happened due to a race condition
because PCU send IND_INFO periodically. As a result, it can happen that
BTS sends an IND_INFO after PCU.clear was called and before the PDCH ACT
is handled.
Commit 446e07bc77 already did same fix for
f_dyn_ipa_pdch_(de)act() family, but didn't change this one.
Change-Id: I323852632341c19837bebfcf2f00d404151367a7
The testcase TC_ts101318_rfc5993_rtp_conversion tests the RTP packet
format conversion of ts101318 to rfc5993 and vice versa. At the moment
the testcase sends RTP packets in both directions at the same time. In
order to simplify the test and to make race conditions less likely, lets
test both directions separately and add some guard time.
Change-Id: Id9b69587f7fb5f6b0da072ac5f4863fd4111e597
The testcase TC_one_crcx_receive_only_rtp performs a short RTP
transmission that lasts about 1 second. Then it conuts out the number of
packets that are transmitted and checks against a fixed value. The
compare values are determined using experimentation and reflect the
number of bytes/packets that one could expect under normal conditions on
an average machine.
However, there may be load sitations on the test host that may cause that
a too little number of packets is transmitted and the test will fail. Lets
reduce the number a bit as the only thing we want to make sure with this
is that there are at least some (more than one or two) packets transmitted
Change-Id: Ie63445d61268d178940ce8d9cfa984519c42041a
The following testcases are carried out using two bidirectional
connections on one MGW endpoint.
MGCP_Test.TC_amr_oa_bwe_rtp_conversion
MGCP_Test.TC_amr_oa_oa_rtp_conversion
MGCP_Test.TC_amr_bwe_bwe_rtp_conversion
The test is programmed in a way that the TTCN3 side of the RTP emulation
also works in bidirectional mode. This is prone to run into a race
condition when the RX side is activated but the TX side is already
transmitting.
However, in order to test if the RTP format conversion works we do not
need to test both directions at the same time. Its perfectly fine to do
the one direction first and then do the other afterwards. Lets also add
some guard time while switching the RTP flows.
Change-Id: Idf257cfc1ab45a7f0fb6e1a2f6426f1b3145879b
Oliver Smith
Neels Hofmeyr
Pau Espin
Harald Welte
Philipp Maier