It was recently decided it's a good practice to always specify the role
and sctp-role for all ASPs configured in the VTY, since it's an
important configuration providing feedback on the network setup
expectancies.
Change-Id: Ia495bc3c5dd4421e5730c74b2f5dc4e4cdc1a673
Until recently, the asp-clnt-* ASPs, which have specific handling in osmo_sccp_simple_client_on_ss7_id(),
were being always forcedly set to sctp-role CLIENT by code in that
function.
This prevented user of that API from explicitly configuring the ASP as
"sctp-role server" through the VTY as the option would be overwritten silently.
Now, the sctp-role from config is followed if the ASP is
defined/configured through the VTY (not dynamically created at the time
osmo_sccp_simple_client_on_ss7_id() is called).
Since the default for a VTY-specified ASP is to be in "sctp-role
server", the config files need to be updated to properly configure the
ASP to be in "sctp-role client", which is the desired mode here.
Same applies for "role", where the default is SG but it is actually used
as "ASP" here.
Change-Id: Idf84502ffa199926a5f0ee616313b515743811ab
Depends: osmo-ttcn3-hacks.git Change-Id I4eb5b5f6b4b24df079b4c74e2a2e2ebb8769b0bd
Try multiple subnet numbers until successfully creating a network. This
way we can run the same ttcn3 testsuite multiple times in parallel
without conflicts (e.g. once against latest, once against nightly). Also
we don't need to make sure each new testsuite has a unique subnet
number anymore.
I've considered also adjusting network_bridge_create, but that gets used
exclusively by osmo-ran/jenkins.sh, a script which we don't actually run
in jenkins. It seems that in this script it makes more sense to not get
a random subnet number.
Related: OS#5802
Change-Id: I57152b08ef0f38e17e7019a8df032189b03f56cf
Use the SUBNET variable instead of hardcoding it in some places. Split
commands across multiple lines while at it to improve readability.
Related: OS#5802
Change-Id: I08f83089ef97f5f92d4bbfa5743301e7375e9f0f
OsmoBSC has supported this VTY interface since more than a year ago.
Let's update the config files to use the new "mgw" node.
The recently submitted VTY commands without the redundant "mgw" prefix
are still not used here in order to have the config file work with
latest release which still doesn't support those.
Change-Id: Iabf117f9e6de02cac16e44d9a0ca32a30d71847c
Related: SYS#5987
Other remotes are mirrors of gerrit one, which means there's some delay
between pushing some ref to the gerrit remote and having them available
in the mirrors.
Hence, it becomes annoying while developing and new stuff to test is
pushed. Let's simply use gerrit since it's the master remote.
Change-Id: Ic87c196f8b91a3a3e6ddde2cca36482ce7070df7
This feature is used to indicate to the BSC that the BTS supports Osmux.
Requires: libosmocore 18c6a8183f92915e77368ecffb1cbf7f555453a3
Related: SYS#5987
Change-Id: Ia402b7514b636750442d0859d5ebc3fcad67dd9f
Add arguments to osmo-bts-omldummy to properly report the features that
were previously assumed for osmo-bts even without reporting them, until
this was changed in osmo-bsc I7fca42a39a4bc98a6ea8b9cfab28c4bad3a6a0aa.
Related: SYS#5922, OS#5538
Change-Id: Ib22f25431330676d59900de7bfb3d89e7872baf1
Allocating a pseudo-TTY (-t, --tty) fails when 'run' is executed
inside of a Jenkins or cron script. This change fixes
ttcn3-bts-test, which invokes 'run' to fetch the config files.
Change-Id: If22f682be4f004c5bb43e65098079a4f4fe6158d
Fixes: If15461240f3037c142c176fc7da745a1701ae3f8
This enables the test suite to obtain talloc reports between the
test case executions, which get stored together with the PCAP files.
Change-Id: Ia9525778fcecc60177be651624e2b2cf9bc75422
So far we were executing all our TTCN-3 tests from a container
image with Debian stretch (9) plus a custom more recent eclipse-titan
package from the osmocom feed.
Let's update the container base OS from stretch (9) to bullseye (11)
while using the same packaged eclipse-titan version (8.0.0) for running
the tests. So this should be a low-risk change, as titan runtime
remains identical.
I've executed all test suites locally and couldn't see any regressions.
Related: OS#4969
Change-Id: Ib3bdfa3bec8f8ef42c55ca61cdee8fbca923874f
Write a line like 'Misc_Helpers.mp_osmo_repo := "nightly"' into the
TTCN-3 config file (e.g. BSC_Tests.cfg), before starting the testsuite.
This allows executing different code paths in the tests based on the
repository.
Related: OS#5327
Change-Id: Ic06532f7a67e59458652c5cf4c8f6fee8113e703
This module parameter is never set to false anymore, since latest
already supports the feature for a while.
The module parameter will be removed soon in osmo-ttcn3-hacks, so let's
drop using it here too.
Change-Id: Idf459365e9aa42f7efd2a418cadea63ec49bdd7a
The purpose is to run osmo-ttcn3-hacks/bsc/BSC_Tests_VAMOS.ttcn with
osmo-bts-omldummy -f VAMOS
(send BTS_FEAT_VAMOS = true).
Change-Id: I2146388bf683cfba99cef5592b8b141c3a6eabb1
Vadim Yanitskiy
Oliver Smith
Pau Espin
Harald Welte
Neels Hofmeyr