2nd TRX arfcn is changed in defaults.conf because multi_arfcn requires
them to be alocated in steps of 4 starting from TRX0.
It is not enabled by default yet on B200 (it must use it to support
several TRX) because current host running osmo-gsm-tester is not
performant enough and cannot keep up with timers due to multi-arfcn CPU
overhead.
Change-Id: I096df82ad1f4cbb41dfbd6a78466a845f34be385
When first suites were added, osmo-nitb was used. Then new tests using
regular split components were added with "aoip_" prefix. At some point
it was clear that osmo-nitb was being deprecated so new tests for split
components were added without any prefix, as they are expected to be the
default one. Since most current and future development is going to be done
for split components, as well as new tests added, it makes sense to move
the few old testsuites using osmo-nitb to have all "nitb_" prefix, while
keeping the split component tests without prefix as it's the regular
network topology.
Change-Id: Idea2e053d337548e0e9b1b47441dbb262124f909
* This commit is a preparation for future commits to add support for
different osmo-trx devices and backends like osmo-trx-lms.
* Drop deprecated osmo-trx-* cmd line params and use VTY cfg to set them.
* As number of osmo-trx related osmo-gsm-tester attributes grow, group
them togther in an "osmo_trx" dictionary.
Change-Id: I77d29413c9e3b600b796627ba366f80c3281b7e1
Since latest release firmware, we have been unable to start up octobts
correctly. As it's annoying having all those tests failing all the time,
let's disable them in nightly builds until we have a working OctoBTS
setup working again.
Change-Id: I828723193564b3a91aeac0c163c7c8c6b7e4058c
Currently only 2 nanoBTS in the 900 band are attached together as a
multiTRX setup. We thus set num_trx to 2 and set channel allocator
descending to force the BTS to use the 2nd TRX when allocating channels.
Change-Id: I12e1bcb047c4efac5693cf725739e0ce2e0532ee
Now that we support modifiers in scenario files, we don't need to
duplicate tests and testsuites to dynamically set trx configuration at
run time. It can be done more easily with scenario modifiers.
Change-Id: I80c441bb5b98d5d2e95d4c6ae1efab3e5f3c40d9
Before this patch, scenarios were only used to select resources with
specific attributes. This commit introduces "modifiers" in scenarios,
which allows setting or modifing config attributes of resources once
they have been reserved. This way same test can be run selecting same
resources but modifying its configuration, allowing for instance running
different number of TRX, different timeslot configuration, etc.
Modifiers are described by placing a "modifiers" dictionary in any
scenario file, similar to the current "resources" one used to select
requird resources. The "modifiers" dictionary is overlaid on top of the
"resources" one resulting from combining all the "resources" dictionary
of all scenario files.
Change-Id: If8c422c67d9a971d9ce2c72594f55cde2db7550d
num_trx is left for now by default to 1, but it has been tested to work
properly (current tests pass and both trx are configured) with
num_trx=2.
Change-Id: Ib3962f824a804e2aa582601475a8514c6cb0d8e7
nanobts IP addresses are assigned through DHCP, and are not local to the
main unit. Let's use another subset for this DHCP pool as we usually use
.50ish for static local IP addresses.
Change-Id: Ibdb0dd97a490aaa555a7bf53cf43cc5a5533a012
The num_trx attribute for a given BTS states the number of TRX to be
used by that BTS. If more than num_trx are configured in trx_list in the
cfg file, then only up to num_trx are taken into account. If a num_trx
value higher than max_trx is specified throuygh config file or at
runtime by the test, an exception is raised explaining the issue.
The num/max_trx attributes are overlayed along the config levels
(generic -> bsc_bts -> specific bts-type -> specific resource object).
This way we can specify a long list of trx+timeslot config in the
generic config (bsc_bts), and tune for each model and specific BTS which
is the desired default number of TRX, as well as the maximum supported
per type.
Change-Id: I7f46eaf7a16f03268653299c93600c0443f691ac
We still want to maintain this file in the same osmo-gsm-tester repo
because we frequently neef to update the config when adding new
features.
Until now only 1 file was maintained (which was used for RnD setup), and
then when runnin in prod the jenkins script used sed to change the file
to accomodate slightly changes. This way is too hacky, so let's just
maintain too separate files, keeping the original resources.conf key
name used by osmo-gsm-tester free, so that jenkins job can symlink one
of the 2 files to it.
Take the chance to remove OctoBTS and Sysmocell5k from the RnD resources
file, as we don't have those them.
Change-Id: Ifec851c7ac6fca6b294e57dfe86b92f214ae8f42
There's no need to specify the IMSI manually in resource config
and it's also prone to errors. Let's take it from ofono.
Add a 'sim' feature to allow modem to auto-discover it,
otherwise if not supported leave that feature out of the config for that
modem and an imsi can still be manually providen.
Change-Id: I20f9e8d97775293925205e4ea576d814214bf1a8
ofono dbus paths are non-deterministic and can change over time for a
given modem. For instance when ofono is restartd or if a modem crashes
and the object is destroyed and re-announced by udev.
Requires at least ofono 1df92289d4e09a1e2db0b189b5153a4c238f98f1, which
implemented the feature to export the sysfs path to modem properties.
Related: OS#2509
Change-Id: Ibc45a196abadded2706dc9d57b6a3a796b43a201
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
Pau Espin
Neels Hofmeyr