After discussion on this thread:
http://lists.osmocom.org/pipermail/openbsc/2019-November/013058.html
Do not expect repeated Paging on GERAN.
Pending clarification on 3G, still expect repeated Paging on Iu, though we are
not 100% certain that this is indeed required.
Fixes MSC_Tests.TC_lu_and_mt_sms_paging_repeated,
but not MSC_Tests_Iu.TC_iu_lu_and_mt_sms_paging_repeated
Change-Id: Ie914ea88f31ac158f4bd1700143bbe728dd05e0b
Fix these tests by using f_mm_common(), which takes care of Iu auth+ciph:
TC_iu_lu_imsi_reject
TC_iu_lu_imsi_timeout_gsup
Change-Id: Id2bf160ac4e1cad4770202c6a6f1b8eeeee21d68
Extra debugging is added because otherwise it's extremely difficul to
find at which state the test is when debugging sporadic failures.
In f_TC_rec_invalid_frame, timer T is reused because it was actually not
being used before, only defined in there.
Change-Id: If24a81bf20d293b87adf9f37111fc7d344f169f5
New generic ms power loop algo takes into account the MS Power sent by
MS over L1 SACCH Header. As a result, the test infra must now update its
transmitted value according to what is requested by the BTS as if it was
a real MS in order for algo to output expected results.
Requires osmocom-bb I975cfc5f5d63eb32a7f8932a7f6a544c9a12233c to have
transmitted MS power values for dummy Meas Results updated as requested
over L1CTL.
Change-Id: I287761202093fbc1064f9868efe6f7f6155253ca
The event FN contains the current FN, but the message should contain the
FN of the first burst of the block.
Change-Id: Iba0b1d1a3d7d875c5443a7bcaff399f9681624ad
Old versions of osmo-pcu print "Osmo-PCU" as VTY prompt. This commit
allows supporting this kind of prompt.
Change-Id: Ia5acbbe5828901726f7f15c4a99d596e94914c4b
If a slotmap is re-created with identical client+bankd, we expect
no change and the client-bankd connection to persist.
If a slotmap is overwritten with a create for a different client
than the currently connected one, we expect the client connection
to be closed.
Change-Id: If81e1511521fe478d2367104cd1c7eba254d6450
Related: OS#4278
Since osmo-remsim Change-Id I83e319d22896b881c0d882542842f500075aa546
createMapping will overwrite any existing mappings that may already
exist for that bank-slot. We need to adjust our test expectations
accordingly.
Change-Id: Ia8de9edd7edb0437cd783b7d045571ff69820c42
Related: OS#4278
In general we don't want that bankd retains state from one test
case to another. Let's issue the new RSPRO ResetStateReq at the
start of each relevant test
Change-Id: If810ccbbc848dd2448a4eaea20c80f60f15a2e84
Function f_rx_rlcmac_dl_block_exp_data() still misses proper
verification of data. Apparently the received message has 2 blocks,
first with expected 10 bytes, but next one contains 18 bytes with 4
actual bytes and other bits are padding.
Last DL ACK/NACK sent is not yet working correctly. osmo-pcu seems to be
unable to match it against sent DL block (I think due to non-matching
FN), and instead drops it and schedules after timeout an IMM ASS to try
to send DL block again.
Change-Id: Icf66dd5c07690368722c586632c38fb7e770053c
In Change-Id I40c6cf7e28ad9331e6c27fe7acafa3f9e277eedf we introduced
a patch that verifies the AMF separation bit for 3G/3G vs 4G
authentication. However, the test ignored the fact that AUTN cannot
be present in pure 2G tuples.
This makes TC_gsup_sai pass again.
Change-Id: I9b61e62a58b583461dd5e67dd12119be282cae21
We added the RAT_TYPE_IE while the respective change in libosmocore
was still in gerrit review. Meanwhile the support there has been
split into two parts: A list of supported radio access types and
another IE indicating the current RAT. Let's catch up with that
in the GSUP implementation.
This makes TC_gsup_sai_eps() pass again.
Change-Id: I2c609dc523cbec562c6c6a05f4c7d600649ff52d
There's also DL_ACK_NACK message for which a template will be introduced
soon, so let's rename and fix typos/wrong descriptions to avoid
confusion later.
Change-Id: I4a2025ad282006953fcfadf429c980b77cb94371
Requires osmo-pcu.git I3430abb5fc622dec293457466e760de95fa3a05c, before
that commit OsmoPCU cmd prompt contained a dash which resulted in TTCN3
being unable to match it.
Change-Id: I221675721b65b3ab44179e9657da70ba4004d7de
This test case checks if the traffic-mode is communicated to the SG if
we operate in ASP mode.
Change-Id: If7d84b73b36a91fb697daf6263ec93b8672cbdc2
Related: OS#4285
Default the MNCC version to the current osmo-sip-connector's master branch MNCC
version.
As soon as the new version (6) is merged, we can bump it here to make tests for
master work again.
For 'latest' builds, we can adjust osmo-ttcn3-hacks to use version 5, and also
see those tests still passing.
Change-Id: I3eb6e0132dc99ebe41a98cc5c329ed4864b770d6
Make sure it is * everywhere, not "". Partially fix the SIP tests, where
tr_MNCC_RTP_CONNECT did not match anymore:
13:15:27.516387 5 SIP_Tests.ttcn:219 Message enqueued on MNCC from SIP_Test-MNCC(3) @MNCC_Types.MNCC_PDU : {
msg_type := MNCC_RTP_CONNECT (517),
u := {
rtp := {
callref := 5001,
ip := 0,
rtp_port := 0,
payload_type := 0,
payload_msg_type := 0,
sdp := "0"
}
}
} id 3
13:15:27.516604 5 SIP_Tests.ttcn:221 Matching on port MNCC .u.rtp.sdp := "0" with "" unmatched: First message in the queue does not match the template:
Together with I522ce7f206932a816a64f03d916799c3215bb8c7 in
osmo-sip-connector.git, this makes the testsuite work again for
osmo-sip-connector master.
In order to fix the TTCN-3 tests for the latest release, we would need
to add a second code path to the TTCN-3 code, that does not send the sdp
data based on a configuration option. Considering that I've spent quite
some time already to fix this up, it does not seem worth the effort.
Related: OS#4282
Fixes: 06b859ca31 ("msc: add sdp to MNCC")
Change-Id: Ic7a2df0b6faeaa88682880f816518618ced79a7e
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
Pau Espin
Neels Hofmeyr
Harald Welte
Eric Wild
Oliver Smith