Commit osmo-msc 098aa71e83a86200a18088927b4753909f5ed518 removes this
option from default configuration as it is really not used in osmo-msc,
it comes from osmo-nitb times.
Change-Id: I928379ebabfc776f33b9f345d92a7a4a533fe25f
So far the resources.conf says we're using XOR, but we wrongly map 'xor' to 1,
which is actually comp128v1 in enum osmo_auth_algo from libosmocore (which
osmo-hlr uses to interpret the numbers from the hlr.db).
This explains why our "xor" tests are succeeding even though libosmocore
doesn't support XOR at all: we were using comp128v1 all the while.
Fix the auth algo mapping:
- define correct mappings, copying enum osmo_auth_algo, in util.py
- add a function to get the enum value from name, in util.py
- use this in osmo_hlr.py
Change subscriber_add() API to take the algorithm string instead of a number.
The number is libosmocore internal and we should not expose it within our API
beyond above dict. There are no callers using this parameter yet anyway.
Adjust resources.conf to indicate COMP128v1 which we are actually using and
which means we're still using algorithm number 1 after this change.
BTW, osmo-nitb uses the ctrl interface which interprets the names, so is not
vulnerable to mapping wrong numbers and needs no fix. (If osmo-hlr featured
similar CTRL, which it doesn't yet, this code could be more robust.)
Related: OS#2758
Change-Id: I7a6ce92468a6ae46136ad4f62381da261fd196c8
This reverts commit 31b7f0f9de.
EC20 actually supports the feature. I was wrong mainly due to 2 reasons:
- I somehow failed to set the modem Online before checking for the
interface, and in that case it is not shown.
- The test I saw failing in prod is due to /gobi_0 being actually a
gobi2000 there, and the once failing was actually the gobi2000 and not
the EC20.
Change-Id: I31ad35b718e20168a75930498901015ca2015a52
At least the signalling support we are currently running, so let's add
the gprs feature to them as they can be used to run the current tests.
Change-Id: I04459786ba76813ebaa7867bcc86afb4fa9700b9
As the interface never appears, tests using the modem fail because we
wait for all the interfaces to be available based on the features
attribute.
Change-Id: I68fcf2b9083966ad42940e1629abe2a1a6b74095
It's difficult to know which path is which, and actually in the prod env
gobi_0 is given to gobi 2000 instead of EC20, which means the attributes
would be applying to the wrong resource.
Change-Id: If17ff9f3d9c4c74bf0aa7966b1dd2f878175a8f0
Only GPRS signalling setup is supported so far by osmo-gsm-tester, thus
we don't test sending data yet here, but at least we can already test
pdp context activation.
This test will be extended to run ping once we support setting up the
GPRS data plane in osmo-gsm-tester.
Change-Id: I8695029cb7a43cd48f650c88f38b4c054da0bc6b
authentication is firmly VLR land and must go away from bsc. That option
is a leftover from nitb. It will be removed at some point.
Change-Id: I3bb4189b33173245116018e437e113c6c1226639
As of osmo-bsc ad47f7108aff5438bd2c6f7c0e898f4aa3b66fbe, this command
has been dropped and is no longer recognized.
Change-Id: Id97074195f045e6872a1a7030671a06259c9ec31
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
... instead of using the one from from osmo vty directly.
This way we avoid having multiple word attribute value and we can skip
using quotes in the conf files.
Change-Id: I5265cc9990dd5e99dba1f6262b3a8c597a3e958d
Before this commit, only max_power_red was specified and it could only
be used as a defaults and could not be set per object. Together with
nominal_power, it can be useful to be able to set them to different
values for different objects, as for example different osmo-bts-trx
objects can require different values.
Change-Id: I472742e98052cc39686d38c945be76d7f50eeebd
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
No need to run it for several BTS as the focus here is testing the core
network and interoperation with different BTS is already tested with the
sms suite. This way we avoid lossing extra time running the default
suite set.
Change-Id: Ie6458801ec1ecce63e08617d1e449047dc496e16
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
A NITB is a BSC + MSC, and if a BTS talks to a NITB, it talks to the BSC part
of the NITB. Hence it makes more sense to name certain things 'bsc' instead of
'nitb', to prepare for a separate BSC process appearing soon.
Change-Id: I6a0343b9243b166d4053cc44f523543f1245d772
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
In the example config and the jenkins scripts, use paths below common parent
dir /var/tmp/osmo-gsm-tester.
1. example: put the state dir in /var/tmp/osmo-gsm-tester/state, instead of in
the config dir like /etc/osmo-gsm-tester.
2. contrib scripts: place trials in /var/tmp/osmo-gsm-tester/trials, and to
move into place atomically, use /var/tmp/osmo-gsm-tester/.prep-trials as
temporary location.
The OsmoGSMTester manual is currently also being updated to setup these paths,
with /var/tmp/osmo-gsm-tester owned by a common group and having group-sticky
as well has group-writable access rules.
Change-Id: I2961e9d1d9b14859b886058b54ffcb36f4d88bc1
/suites will be the definitive GSM tests collection where everyone should contribute.
Since we're using /example on our current osmo-gsm-tester setup actually as-is,
change paths.conf to point at ../suites.
Change-Id: I7a4d0161d3dcb3a0c723b0b96db85dd032cc2159
Pau Espin
Neels Hofmeyr
Neels Hofmeyr