The gb_index was forgotten to given to the new function f_send_l3().
All testcases which only used the default BSSGB connection #0 continued
to work, but the TC_attach_rau_a_b is the only testcase which uses #0
and #1 at the same time.
Fixes: a05b807922 ("sgsn: Add TC_llc_null to test if SGSN survives a LLC NULL packet")
Change-Id: Ie3dd8c613d3b3440447a282dc4545078cb927274
Commit 0ac6315212 breaks all related GSUP SS tests because it require
all GSUP SS packages to have a OSMO_GSUP_MESSAGE_CLASS_USSD IE.
Change-Id: Iadbc37105fa67cf6383fb63b86ed653ccc7bddf7
We used to support sending of LLC messages only for the MS role,
where we generated BSSGP UL UNITDATA. Let's also support the
SGSN role, where we have to generate BSSGP DL UNITDATA
Change-Id: If86f4b7c9e7c3c799c274f37a350dec4a788f124
it seems that some part of the code was commented out, breaking
the path where a ConnHdlr is sending a L3 MT message.
Change-Id: Ie652598292f2fbd2e1e0c4aa679ff0d68d78c88c
Let's make sure the related functions can be used on other gb_idx,
i.e. via another Gb interface (and hence simulated RAN/PCU) than
the first one.
Change-Id: Ie88cbf0c70269cc3e2c2fd2a0c65c8f2130ec2b1
Introduce a function to verify there's no duplicate ProtocolIDs
in the PCO returned from the GGSN.
Change-Id: I9d439dab1696196cd125f4d7113b426f1711a405
Related: OS#3914
We need to check explicitly for '== null'. isvalue() is of no help
here, as 'null' apparently is a value in TTCN-3.
Change-Id: I4b2793937a201c5535051092d871ded6cb053f5f
Tests like TC_lu_imsi_reject, TC_lu_imsi_timeout_gsup and
TC_cmserv_imsi_unknown all expected a reject straight in response
to the LU REQ / CM SERV REQ. However, the MSC may very well decide
to perform authentication beforehand. It's an implementation
detail when a MSC/VLR performs authentication, so the tests should
be tolerant to this.
This primarily shows up in 3G/Iu/RANAP related tests, as authentication
is mandatory there.
Change-Id: Icdd3f34eca08092703ab2ba9a8e755e2d609a59b
We were using '?' for the protocolExtensions in RANAP messages,
which required that such extensions existed. In reality, we want
to use '*' which accepts paging messages whether or not there
are any protocolExtensions present. As this is the default in
all our RANAP receive template, callers don't even need to specify
it.
This should fix all Iu paging related test failures in MSC_Tests*.ttcn
Change-Id: If22e16ecb301c86b9073ffde0af9e03bc85fbcc7
Both f_mo_call_establish() and f_mt_call_establish() were testing barely half a
voice call setup. For example, f_mo_call_establish() used to be satisfied with
just two CRCX, but no actual RTP connections being made.
Add numerous MNCC and MGCP messages more closely resembling an actual call.
The main reason is to achieve a state that passes both current osmo-msc master
as well as the upcoming inter-MSC Handover refactoring.
Add log markers to f_*_call_*(): often when a test halts, it is not at all
clear why. With these log markers it is saner to figure out what has happened
and what hasn't.
Change-Id: I162985045bb5e129977a3a797b656e30220990df
Randomly, this test issues the Clear Command so fast that the MGW has not yet
been set up, and hence the test cannot possibly see DLCX for endpoint conns
that haven't been set up at all. So, simply wait a bit before clearing.
Change-Id: Idd0b3810916efd02a499e0ac060a6a275265b8c3
This function is required not only for the MSC_Tests, but also for
the upcoming Iu related SGSN tests
Change-Id: Ic23669671ce79151046f2330726bb68542faeb0e
This might look a bit like copy+paste programming for our testcases.
However, we actually want the Iu related tests show up as separate
'testscase' in the TTCN-3 sense, so there's no way that's more elegant
than this :/
Change-Id: I3b56e17487c9df839e67ed390a1ff89979683e8e
The new function will check the RAN type and dispath to
f_bssap_compl_l3() in case of 2G/GERAN and to f_ranap_initial_ue()
on case of 3G/UTRAN.
Change-Id: Ia27afa265d441d1a0cbb40cc2d938aff46fa25f9
Particularly the C++ files generated for the rather comprehensive
3GPP asn.1 specified protocols like MAP, RANAP, ... result in very
large source files and subsequently g++ processes that consume well
into the multiple gigabyte range of memory.
Let's use the '-U 5' option to ask the ttcn3_compiler to split all
c++ files into 5 chunks, resulting in more files to compile, but
smaller individual files.
I also tested '-U type' before, but it was still grinding my 16GB RAM
laptop to unusable deep-swapping state when running 'make -j8' for
the IuCS extended MSC test suite.
Change-Id: I013b623e98d58a39dd7bb2b0db4a911725028535
The module parameter mp_ipa_up_delay ads a delay after the ipa bring up.
This is relevant for the tests with real BTS hardware, but it is not
relavent for the regular TTCN3 tests.
Lets set the default to 0.0, since the delay caused problems with
TC_rsl_ms_pwr_ctrl and TC_si_sched_13_2bis_2ter_2quater.
Change-Id: I7663cad5df1ee5a8bcdbbf522881999f1be9f4fe
Related: OS#3960
So far, RAN_Emulation only handled BSSAP and hence could be used
to emulate BSCs towards the MSC. Let's extend it with RANAP support
so we can also emulate RNCs towards the MSC.
We try to share as much code and logic as possible betweeb the two.
Related: OS#2856, OS#2857
Change-Id: Ie79bda764162e5c5a42608bde5c5f486ea531f33
This patch introduces protocol codecs for the HNBAP, RUA and RANAP
protocols, which is mandatory for testing IuCS, IuPS or Iuh in
the future.
As Eclipse TITAN ASN.1 only supports the BER codec and the above
protocols all use APER, we need to use an external transcoder from
APER to BER and vice-versa. This was implemented using a proprietary
ASN.1 compiler / trnaslator which sysmocom is packaging as
libfftranscode, which is made available as binary package
for Debian 9 at https://ftp.osmocom.org/binaries/libfftranscode/
Related: OS#2856, OS#2857, OS#2858
Change-Id: If4a72de9bc54d6e6a7daaca78a4d4aa5684203a5
The RAN_Emulation currently unconditionally provides BSSAP and MGCP support.
Let's re-structure the code so that support for those protocols is now
possible to enable/disable at compile time.
This patch is in preparation of introducing RANAP support in RAN_Emulation.
Change-Id: Id53ba3ff05f9946230e0e4a759245de14a0f9fbd
Related: OS#2856
This test case reproduces a bug in OsmoSGSN where it would crash
as a result to sending LLC NULL frames.
Change-Id: I38326f2ebaaff009d4357edad9511ce2ce7736fd
Related: OS#3952
When running tests with real hardware it is important to wait for some
time (3 sec. should be enough) before exiting f_init(). This is to
ensure that the BTS supplies a stable carrier before the test proceeds.
Change-Id: Ib78633a33a15cd40514e15b6ebf9a0a8fb7b9c68
Related: OS#3863
The default value for the module parameter mp_ipa_up_timeout is set to
10 sec. Given that the sysmobts needs around 10-11 sec. to perform one
restart cycle this is to low and causes tests to fail occasionally. Lets
increase the default value to 15 sec to get reliable.
Change-Id: I5bb290d00a02a25672305688352a03f3bf484ff3
Related: OS#3863
According to 3GPP TS 04.60, section 11.2.5a, the extended (11-bit)
Access Burst on RACH/PRACH is used by the MS to indicate its EGPRS
capability. One of the alternative synch. sequences (see 3GPP TS
05.02, TS1 and TS2) shall be used.
Add a test case to verify extended (11-bit) RACH decoding.
Depends: (OsmocomBB) I36fd20cd5502ce33c52f644ee4c22abb83350df8
Change-Id: I8fe156aeac9de3dc1e71a4950821d4942ba9a253
Related: OS#1854
According to 3GPP TS 04.60, section 11.2.5a, the extended (11-bit)
Access Burst on RACH/PRACH is used by the MS to indicate its EGPRS
capability. One of the alternative synch. sequences (see 3GPP TS
05.02, TS1 and TS2) shall be used.
Change-Id: If037cb2f2687697f168d10a033eeb20d20183328
Related: OS#1854
This allows to start ConnHdlr on specific RAN connections, i.e.
on different emulated BSCs (and soon RNCs).
Change-Id: I3d7ec567a7b69d8c6f79d26971bf1c94e077d5f5
So far, BSSMAP_Emulation supported only a transport over BSSMAP.
However, we soon intend to merge support for RANAP in order to
simulate RANAP/Iu connections as well as BSSMAP. Let's start
by renaming some of the existing types/functions/ports/modules
without introducing any functional changes just yet.
Related: OS#2857, OS#2856
Change-Id: Iecbcb0c6c136baad9460eca40606bb4010d8882d