When introducing IPv6 support, we map the third digit of the IPv4
address (X) to the 6th byte of an IPv6 prefix "fd02:db8:X::/64"
However, the docker daemon seems to use "fd02:db8:1::/64" internally
for its default network, so creating a docker network with the same
IP address is failing.
Let's move the MSC test suite to another sub-net (1->20) to avoid
related problems.
Change-Id: I9c5f9b96d5523eae09f3f2e6c813e9e0d047f9ab
Configure each osmo-* program to send GSMTAP log output to the IP of the
docker container, which runs the testsuite (and therefore runs tcpdump).
Related: https://lists.osmocom.org/pipermail/openbsc/2019-June/012946.html
Change-Id: I99e74f6ffb5b7d566cec35995bf067df414968d8
We need to update the MSC_Tests.cfg as well as the osmo-stp.cfg
to provsion a virtual RNC link. As the new RNC uses routing key 2,
we shift the MSC routing key to 3.
Change-Id: I10a249b1a851436fd3c20face6ccc94b304bd3e4
the routink key for virt-bsc0-0 and virt-bsc1-0 is the same
(0), virt-bsc0-0 and virt-bsc1-0 should use different routing
keys.
- Keep the routing key of virt-bsc1-0 and assign routing key 1
to virt-bsc1-0
Change-Id: I1380ba389dc777cdac84677588b85759cad4bc14
In Change-Id: Ie7780750f7032453951f6849ecee6ab7cc34e8c2 we not only
introduced a MSC_Tests.default with syntax errors, but also a
osmo-stp.cfg with syntax errors :((
Change-Id: If7a7ff3d7ddb255654d14fe17033390214fe5341
The MSC_Tests.ttcn testsuite is now able to present multiple BSC
to the MSC (IUT). This change requires the configuration files
of osmo-stp and of the testsuite to be changed.
- update MSC_Tests.cfg to present up to two BSCs to the MSC
- update osmo-stp.cfg to support the additional connection
from the testsuite
Change-Id: Ie7780750f7032453951f6849ecee6ab7cc34e8c2
Depends: osmo-ttcn3-hacks I52a4c8118828c1605cf672889982f987568ad17d
Related: OS#1609
Ideally we would want to launch a group of containers with their own
private network segment and use the same static IP addresses in those
isolated networks.
The stupidity of docker is requiring unique IPv4 addresses even on
isolated (!) networks. This means we have to manually give each of our
test setups a different subnet, and then we can at least run one
instance that test in parallel to at most one instance of each other
test.
If this weird reestriction about unique IPv4 addresses didn't exist,
we could start any number of test runs in parallel.