I first wanted to use "reset" method, but according to [1]:
"The recommended practice is to drop the reference to a
cancellable after cancelling it, and let it die with the outstanding
async operations. You should create a fresh cancellable for further
async operations."
Pretty weird that in other parts of documentation it still says that it
can be used for concurrent events.
[1] https://developer.gnome.org/gio/2.54/GCancellable.html#g-cancellable-reset
Change-Id: I7392275620576fd0037be5b9d9f360a46a4f8312
osmo-sgsn change-id I91a126952ae75ae9ba1f42aac4d26413384bba5d and commit
a3b73e917b653d13d027cff2c95a56bbc1264446 has broken compatibility with
openggsn.git, by requiring current osmo-ggsn version (1.0.0).
Fix build fallout: use osmo-ggsn instead of openggsn.git.
Change-Id: I5161983ef625465e21b95578ab5648ecc73d6069
The previous commit wrongly placed all of 'osmotrx' below 'instance 0', put the
'osmotrx ip' ones back in the parent (I3a48cda44b932b46f34f027ca88e3703b6f04bad
-- I should have known, the change Id ends in "bad").
The correct structure is:
phy 0
osmotrx ip ...
instance 0
osmotrx rx-gain ...
osmotrx tx-attenuation ...
i.e. the 'osmotrx' command name exists on both the 'phy' parent level as well
as the 'instance' child level. (Argh, can this be more confusing? I assume we
will be seeing a continuous flow of users hitting this now.)
Change-Id: I7ef7ab3048266c1b2a4f6f33951f1305ec5f0ad6
We hit this now because libosmocore has started strictly enforcing correct
indenting of child nodes. See I24cbb3f6de111f2d31110c3c484c066f1153aac9.
Change-Id: I3a48cda44b932b46f34f027ca88e3703b6f04bad
Same code is already being used by log.Error exception.
This way we can use:
raise resource.NoResourceExn("No free arfcns in any of bands", bands=supported_bands)
And get:
osmo_gsm_tester.resource.NoResourceExn: No free arfcns in any of bands {bands=['GSM-850', 'GSM-900', 'GSM-1800', 'GSM-1900']}
Change-Id: Ic960ae8db5372b0a4640356f0b4820ed42477b46
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
Now that combination and matching of lists works properly, update the
suite test to check a more complex scenario.
Change-Id: Ib0b82dc0c2a7f27cd6b2ffc32eed5f1287692ddc
We want to handle lists in the same way as we handle them in combine().
Without this commit, reserve()->find() failed to match objects
containing dictionaries inside lists correctly (such as trx configs).
A few attributes are added to trx_list of some resources in
suite_test/resources.conf to show a case in which resource reservation
would fail without this patch. It failed because before this patch,
dictionaries inside lists are compared to be equal instead of being
compared element by element to see if one dictionary is a subset of the
other one (for each element in the lists).
Change-Id: I8588d5b788b9f74a9cc84b8bdcb049921788bb48
This commit fixes combination of resources containing lists.
For lists containing complex types, it has been decided to handle them
as sorted list, where position in list matters. In this case, combine is
called recursively for each element in dest and src sharing position in
the list, and assumes that if one list is shorter than the other, then
it has to be combined against empty set for that tye.
For instance this is useful when defining trx_list properties, where a
BTS can have a different amount of TRX but we may be interested in
restricting the first TRX and don't care about extra TRX.
For lists containing simple types (eg. integers or strings), we just want
to merge both lists and we only need to check if the value is already there,
ie. handle them as unsortered sets. This case won't work if we call combine
for each element of the list because for a simple case it will just end up
checking if a[i] == b[i].
This kind of operation for simple types is needed in later commits where
cipher attribute is introduced. Without this patch, having following 2
scenarios and trying them to use together "-s foosuite:cipher-a50+ciphera51"
will fail:
cipher_a50.conf:
bts:
- ciphers:
- 'a5 0'
cipher_a51.conf
bts:
- ciphers:
- 'a5 1'
ValueError: cannot combine dicts, conflicting items (values 'a5 0' and 'a5 1')
Change-Id: Ib7a38f10eb9de338a77bf1fa3afceb9df1532015
As suite.conf and scenarios need to match 1-to-1 in lists, it's important to
extend the dictionaries by replicating the objects with a 'times' values
higher than 1 in order to match the objects correctly.
Since dictionanries are expanded at combine time, there's no need to
expand them during reserve() time because they are already expanded.
As a result, this commit reworks the kind of schema applied in each
place (and takes the change to start validating scenario files, which
were neglected previously).
Two unit tests are added as a show case. Unfortunately output showing
scenario dictionaries needs to be ignored while verifying because it was
encountered that different versions of python print dictionary elements
in different order.
Change-Id: I25eb639c7e3cf3b4c67a205422808bffbdd791e6
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
In the following suite.conf, position matters when matching against scenarios:
[suite.conf]
resources:
bts:
- type: sysmo
times: 2
- type: osmo-bts-trx
times: 1
[scenario]
resources:
bts:
-
- ip_addr: 1.2.3.4
In this case, for instance, we make it clear that we want the second
sysmo bts which has IP 1.2.3.4. With old behaviour, the replicated sysmo
would have been created at the end (3rd position), and the ip_addr would
match against the osmo-bts-trx BTS.
Change-Id: Id78e2326db964d5efb6648854b57d8addce4deb0
This is a first step to add support for osmo-bts-octpy to
osmo-gsm-tester.
There's no point in building separate insts for different osmo-bts
variants which run on the main unit and which come from the same git
repository, this we make the osmo-bts-trx one generic to handle all
variants which fall into the description above.
Tested locally on my laptop that it builds susccessfully.
Once this patch is applied, jenkins jobs need to be adjusted:
- RnD: osmo-gsm-tester_manual-build-all
- Prod: osmo-gsm-tester_build-osmo-bts-trx (and rename it)
Change-Id: Ib8814e4ce49596b586990f20d7d625a719852e90
An issue was spotted recently in tests run in production which call
modem.connect() twice, first time to check that we are unable to connect
with a wrong KI, then that we can connect with the correct KI.
As there's no current easy way to wait for "rejected" signal, we
basically wait for some time before checking if we were unable to
connect. It seems that sometimes waiting for 30 seconds is not enough,
and then a scan() async method is still in progress when we decide to
call connect() again, which will powercycle the modem. If the scan()
method returns at that time, then we try to access interfaces of the
modem which are no longer available because the modem is powered off at
that time. This triggers an exception and test fails.
To correct way to fix this is to make sure we disable pending Scan()
dbus method before powercycling the modem and starting a new Scan()
method.
The sleep time is also increased to make sure we let enough time to
register. It seems it can take about 15 seconds to do a full scan, and
sometimes during first scan iteration the BTS is still not found,
probably because it's still starting.
Related: OS#2510
Change-Id: Ic4bb1c6b72c23cd860c33bee7851bca3d0ac0e1b
Do not pass os.O_TRUNC to open(), that immediately empties out the lock file.
Fix lock_test to be able to catch this error. So far things were happening too
fast to notice it.
Caught by running 'make check' on a main unit APU that has different timing
behavior.
Change-Id: I872a3d2548ac84097ac7acf13cb12c36822e076e
We are currently seeing this issues in prod setup, which uses python
3.4:
File "/home/jenkins/workspace/osmo-gsm-tester_run/osmo-gsm-tester/src/osmo_gsm_tester/bts_osmotrx.py", line 44, in __init__
self.pcu_sk_tmp_dir = tempfile.mkdtemp(None, 'ogtpcusk', None)
File "/usr/lib/python3.4/tempfile.py", line 432, in mkdtemp
file = _os.path.join(dir, prefix + name + suffix)
TypeError: Can't convert 'NoneType' object to str implicitly
Acording to mkdtemp man in python3:
"Changed in version 3.5: suffix, prefix, and dir may now be supplied in
bytes in order to obtain a bytes return value. Prior to this, only str
was allowed. suffix and prefix now accept and default to None to cause
an appropriate default value to be used."
This issue went unnoticed because the RnD env is running debian 9, which
probably has python version >= 3.5.
Change-Id: If3226183fe21b4820149b1d03207193dc6f139e2
The jenkins scripts are run by sh, which does not support the {a,b} syntax
shell glob. As a result, old build artifacts pile up in the workspaces.
Use two separate lines to remove .tgz and .md5.
Change-Id: Ib7e5995aa6914e34f8b7bbb8a8ed46ff9230a913
In commit 329b6f4 pcu-socket path was moved to run inside the test run
dir to avoid issues between different tests creating a socket in the
same place.
However, it seems unix sockets paths are limited to 108 bytes (with Null
char included). In some cases, the run dir for a test can be quite long,
as it contains suite name, test name, etc. and the path can be longer
that the limit defined above.
In order to fix this issue, create a tmp dir using mkdtemp to ensure the
path to be used for the pcu-socket doesn't collide between different
instances of osmo-bts-trx.
Clean up of tmp dir and pcu socket is done inside the cleanup() method
called by suite.py.
method pcu_socket_path() is added to help with new implementation, and
it will be used as well as a public API later soon to be used by OsmoPcu
classes.
Related: OS#2507
Change-Id: I0c53a0a3ccc5eb2823265fe14c0f7b8f4adb1038
In following commits, cipher attribute containing a list of supported
ciphers is introdued in osmo-gsm-tester. While developing the feature,
it was found that resources containing lists are not being handled
correctly.
Previous implementation regarding lists in several ways:
- In the list coe path, both item and wanted_item are expected to be
lists. Python doesn't support to check for sublists using the "in"
operand.
- want_item basically contains the scenario dic, and item is each of the
items available as resource of a given type. Thus, we want to check that
item supports the subset of features requested by the scenario, ie. that
the list in the scenario is a subset of the ones in the3 item and not
the opposite.
The following failing scenario is going to be checked during "make check"
when the cipher attribute is added: BTS supporting cipher a50 and a51,
and scenario requesting a50 succeeds. If this commit is remove, the test
no longer passes, and it fails with:
osmo_gsm_tester.resource.NoResourceExn: No matching resource available for
bts = {'type': 'osmo-bts-sysmo', 'ciphers': ['a5 1']}
Change-Id: I27b372aa5906feac2843f24f5cdd0d9578d44b4d
The purpose of this patch is to make sure we output to the extended log
some information regarding the firwmare version of the modem being used,
even if the test being run doesn't call print(modem.info) explicitly.
Printing self.info() just after waiting for Powered==true doesn't always
work, because the properties are not populated after a while after.
Calling Modem.GetProperties() immediately after receiving Powered==true,
will provide with empty strings on properties such as Revision.
18:59:55.747412 bus /sierra_1: Setting Powered True
18:59:55.938889 bus /sierra_1: DBG: 'org.ofono.Modem'.PropertyChanged() -> Powered=True
18:59:55.964694 bus /sierra_1: DBG: Powered == True
18:59:55.987777 bus /sierra_1: DBG: interface enabled: org.ofono.VoiceCallManager
18:59:56.006278 bus /sierra_1: DBG: 'org.ofono.Modem'.PropertyChanged() -> Features=[]
18:59:56.027366 bus /sierra_1: Setting Online True
18:59:56.189991 bus /sierra_1: DBG: 'org.ofono.Modem'.PropertyChanged() -> Manufacturer=Sierra Wireless, Incorporated
18:59:56.210935 bus /sierra_1: DBG: interface enabled: org.ofono.LocationReporting
18:59:56.233217 bus /sierra_1: DBG: 'org.ofono.Modem'.PropertyChanged() -> Features=['gps']
18:59:56.255807 bus /sierra_1: DBG: 'org.ofono.Modem'.PropertyChanged() -> Model=MC7304
18:59:56.279374 bus /sierra_1: DBG: 'org.ofono.Modem'.PropertyChanged() -> Online=True
18:59:56.315008 bus /sierra_1: DBG: Online == True
18:59:56.338779 bus /sierra_1: DBG: interface enabled: org.ofono.SimManager
18:59:56.357744 bus /sierra_1: DBG: 'org.ofono.Modem'.PropertyChanged() -> Features=['sim', 'gps']
18:59:56.379532 bus /sierra_1: DBG: 'org.ofono.Modem'.PropertyChanged() -> Revision=SWI9X15C_06.03.32.04 r28324 CNSHZ-AR-BUILD 2015/05/25 01:09:15
18:59:56.401241 bus /sierra_1: DBG: 'org.ofono.Modem'.PropertyChanged() -> Serial=356853054230919
Change-Id: If215c7d63ce1b86314ed25f8e76413b15676b7f5
Drop the second 'rm -f' from the rm shell command (typo).
Remove all artifacts matching *.build-*.{tgz,md5} because if a job changes the
name of its artifact, the previous artifacts would remain.
(I hit this with the new scripts being originally wrong and all producing
'osmo-msc.*' artifacts, and those stuck around in the workspace even after the
name was fixed.)
Change-Id: I00d246226f4c723696bb737ed707cfd0e4c33714
The idea is to build each binary separately: even though osmo-msc requires
libosmo-sccp, which already includes the osmo-stp binary, we still want
osmo-stp to be built from a separate script. The reason: to track down
regressions, we can change the versions each binary is built from separately.
The additional build effort and jenkins script multitude is acceptable.
Change-Id: I194ad5169dbe013c8e1cf9d631033cb2576744dd
Recent change Ib1a00b2149453fedf9ece0460dd4d6e83f774d45 drops binaries from a
build artifact by leaving only explicitly requested ones. This adds a check
that the requested ones indeed exist.
Change-Id: Iceddeee6aebb1cdb54d7304495c3e332390261db
Each of the jenkins-build-* scripts intends to build a specific set of
programs. While compiling dependencies, other programs may end up in
$prefix/bin. Drop those other binaries to reduce potential confusion.
Add arguments to the create_bin_tgz function: callers need to list exactly the
$prefix/bin/* binaries that should be tar'd. All others are first removed from
the prefix.
Adjust existing scripts to provide such binary names.
Change-Id: Ib1a00b2149453fedf9ece0460dd4d6e83f774d45
Register() method returned today this error which is expected acording
to ofono documentation API. In this case it probably happens because the
modem internally starts registering at some point between the time
Scan() is finished and we call Register(). In this case it is fine for
us and we should just ignore the error.
A helper method is added to check for this as so far it seems tricky to
check error information coming from pydbus. I could not reproduce this
issue locally so I could not test that the helper function is going to
handle it correctly when it is triggered. That's why I added extra debug
information to be able to fix it next time it is triggered.
File "/home/jenkins/workspace/osmo-gsm-tester_run/osmo-gsm-tester/src/osmo_gsm_tester/ofono_client.py", line 489, in scan_cb_register
dbus_op.Register()
File "/usr/local/lib/python3.4/dist-packages/pydbus/proxy_method.py", line 75, in __call__
0, timeout_to_glib(timeout), None).unpack()
GLib.Error: g-io-error-quark: GDBus.Error:org.ofono.Error.InProgress: Operation already in progress (36)
Change-Id: I58dda09416ee7328812431220fd3d239c5c2980a
Attribute trx_remote_ip is actually using IPv4 validate type, thus this
validate type is not needed.
Change-Id: Ia8e154ac5fe33932935ba049f08eb5af15195d99
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
Nowadays encryption parameter in bsc needs to be set to the same cipher as
the one specified in msc, otherwise the cipher negotation will fail.
See OS#2461 for more information on the matter.
Change-Id: I857b3860fb771b36fb3d587d4e92b320f0685a19
Pau Espin
Neels Hofmeyr