Since Change-Id Ia2882b7ca31a3219c676986e85045fa08a425d7a, osmo-bsc
uses osmo-mgw and utilizes libosmo-mgcp-client to talk to it.
This commit fixes latest constant failures in voice suite.
Change-Id: I1dadd781a357fce33e7bde55e4bcbdaeb4633359
Our current Octasic license has multi-trx support disabled and the board
rejects the configuration.
Change-Id: Id2c415deb85187feb42fb6d24cc86273eb722936
Specific parts for this class:
- Runs osmo-bts-octphy binary, that requires CAP_NET_RAW capability
because it uses an AF_PACKET socket.
- As a consequence, it must use the previously added APIs to set the
capability and modify the RPATH of the binary before launching it. These
APIs require extra host setup and installed dependencies that will be
documented soon in osmo-gsm-tester manual.
- A num_trx() helper method is added because the binary requires that
parameter.
- A allocate_phy_instances() is added to help build/fill the conf
dictionary to be used in the tmpl to be able to easily set up trx, phy
and insances.
A config to use a osmo-bts-octphy at full power is used (4 trx) is added
in this commit to show how can it be configured. However our
current license only has support to use 1 TRX, and so next commit drops
most configurations to simplify the setup to use only 1 TRX.
Change-Id: Ia350964fa539083bb68d439cad0caa8fdf85d297
The idea behind this attribute is similar to the Features one in ofono:
To provide an easy-to-use list of features that a modem supports.
In osmo-gsm-tester this feature list can be used to create scenarios to
act as a filter for modems. For instance, if an sms related feature must
be tested, then a modem supporting sms features is required. This way
only modems supporting that feature are going to be selected for that
test when that scenario is used.
We provide our own list instead of dynamically using it for two reasons:
- Accessing the list from ofono means powering on + online the modem,
which requires using the modem before resource resolution is done.
- ofono may state that it has support for feature X, but it still
doesn't have all features required by osmo-gsm-tester or there is a bug
in some part of the feature which prevents it from being used for a
specific test.
Change-Id: I1634049f01859ae0310174892a96e204bb670bc1
This parameter is contains a list of supported encryption ciphers by the
modem or bts setting it. It is so far not directly/automatically used
inside osmo-gsm-tester code, but can be useful to create scenarios for
tests that require specific ciphering modes.
For instance, aoip_encryption suite contains tests that require a BTS and
a modem that supports a5 0 and a5 1, otherwise tests will fail.
Change-Id: Ic0e368843a6e58bd3eeef36d2c0a7501296f0f3e
Algorithm to use to generate response for the challenge during
authentication time is hardcoded in the sim card and cannot be easily
changed. Thus specify in the config of each modem the algorithm used by
the SIM Card. This attribute is used add subscriber_add() time, when the
IMSI, KI and algorithm to use in the MSC to authenticate a given
subscriber is stored in the database. This way we can easily set up
a specific algorithm for each SimCard/Modem, in case different SimCards
are configured with different algorithms.
This can be used to specificially test different algorithms too. For
instance, let's imagine we have 2 simcards, one configured to use comp128v1
and another one with xor, and we create a test which ckecks that XOR is
algo is working fine. We don't want to accidentally select the modem
with comp128v1 in this case. Thus we can use this attribute to create a
scenario file matching 'auth_algo: xor' to ensure always the correct
modem is picked.
Change-Id: Ifdf74630afeb05452994bbc9eb62a745a1d745ce
This way we can run tests with a specific instance of an osmo-bts-trx,
for instance we may want to run some tests with an Ettus B200 and also
with a sysmoCell 5000.
Change-Id: I5fd78d79b8bfab8ccacc4666563b66b6da9f2bde
We may want to support running a device which runs its own TRX
(osmo-trx or different implementation). Furthermore, this TRX may be
available in some specific hwardare rather than on the main unit.
This makes it easy to configure OsmoBtsTrx to launch it's own
osmo-trx or not. In case it is launched, all IPs are configured correctly
to ensure connection can be established.
Before this commit, osmo-trx was binding to 127.0.0.1. Now we can
support multiple osmo-trx being launched on the main unit.
Change-Id: I825ed1fc0c3fe75d196db90c1508283fbd04acf8
This seems to be the default address used to communicate via SSH with the
sysmoBTS. Whichever process ends up getting this address sees all of the
SSH in its pcap (for the AoIP build it tends to be OsmoHLR).
We could filter properly, but actually also just take this address out of
the pool for allocation to server processes.
Change-Id: I07e74ba0b9a5b08a308aae7646c4b7c70fe4aa0e
The upcoming BSC+MSC+HLR+MGCPGW style will need four IP addresses. I found six
already configured on the main unit, so adding all of them to our
resources.conf.
Change-Id: Ie0e0ed9bb7fbd87ebe630c32ef59659117d77ed8
I would like to use the IP addresses also for OsmoBSC processes, so it is more
than clear now that 'nitb_iface' was the wrong naming choice.
The only distinction we may need in the future is public versus loopback
interface. To add that, we may add a trait to the 'ip_address' resource
like:
ip_address:
- addr: 10.42.42.1
type: public
- addr: 127.0.0.1
type: loopback
This way we can substitute public vs loopback addresses flexibly (e.g. using
scenarios).
Change-Id: I3ad583ae7a33f7a7bb56fe78a125f73c56a0e860
Pau Espin
Neels Hofmeyr
Neels Hofmeyr