path: root/example
AgeCommit message (Collapse)AuthorFilesLines
2017-09-14Reserve ARFCN dynamically based on BTS band supportpespin/arfcnPau Espin Pedrol4-4/+8
Instead of statically specifying a band for a BTS to use, declare a list of supported bands for each BTS. At the time of BTS object creation, ask the BTS for band support and try to dynamically reserve an ARFCN resource which is compatible with any of the bands supported by the BTS. All this happens transparently to the test. Still, the test may want to use a specific band / arfcn. In this case, a test can use suite.reserve_arfcn(band, arfcn) to reserve a specific band/arfcn and pass that to the BTS at creation time, which will then use that one instead of trying to find a suitable one. It is left as future work to support BTs with multiple TRX, in which case several arfcn must be reserved. It should not be that difficult, mostly using "times: X" where X is the amount of trx, changing the API to use a list of arfcns and the configure() methods of the BTS. Related: OS#2230 Change-Id: I6fb5d95bed1fa50c3deaf62a7a6df3cb276bc3c9
2017-09-14Add features attribute to modemsPau Espin Pedrol2-0/+8
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
2017-09-14Add cipher cfg param for modem and btsPau Espin Pedrol4-1/+22
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
2017-09-14Use own format to specify encryption algorithmPau Espin Pedrol1-3/+3
... 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
2017-09-14nominal_power and max_power_red attrs can now be set per resourcePau Espin Pedrol1-1/+2
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
2017-08-25default-suites.conf: Add suites to explicitly test with sysmoCell5000Pau Espin Pedrol1-0/+2
Change-Id: I6ff08a281c0c32148ca2c59f731d6550bf7b1c90
2017-08-24Introduce aoip_encryption suitePau Espin Pedrol1-0/+1
This suite aims testing different authentication and encryption setups. Change-Id: I5816ecc19a818e5b821fbc6272c9f37f9650ae10
2017-08-24Introduce auth_algo modem config attributePau Espin Pedrol1-0/+4
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
2017-08-23Add support for authentication VTY param in msc and bscPau Espin Pedrol1-0/+2
Change-Id: Ie1eb76149d4b006631050f8a1e532fbdbdad6a7f
2017-08-23Add scenarios for each osmo-bts-trx typePau Espin Pedrol4-3/+11
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
2017-08-23bts_osmotrx: Support configuring bts addr, trx_remote_ip and launch_trxPau Espin Pedrol1-1/+9
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 Now we can support multiple osmo-trx being launched on the main unit. Change-Id: I825ed1fc0c3fe75d196db90c1508283fbd04acf8
2017-08-23resources.conf: Remove empty linePau Espin Pedrol1-1/+0
Change-Id: I821bff68ce3a4a81a9deb79e6302bd7c341a8255
2017-07-05default-suites: Add smppPau Espin Pedrol1-0/+2
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
2017-05-29default suites: enable osmo-bts-trx (Ettus B210)Neels Hofmeyr1-0/+2
Change-Id: I5dce732ed21f34988aa014add4d2d611dd0c44fc
2017-05-29resources.conf: take out Hofmeyr1-1/+0
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
2017-05-29default-suites.conf: run aoipNeels Hofmeyr1-0/+1
Change-Id: I0f7d6feec5062c2aaf07eb9a7f543a4a84cb1ff7
2017-05-29MSC+BSC: add test api to run OsmoMSC and OsmoBSC with AoIPNeels Hofmeyr1-2/+20
Change-Id: I5842e8f1cba8e8e6bedfc08540efcafe207159cb
2017-05-29resources.conf: more IP addressesNeels Hofmeyr1-0/+3
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
2017-05-29rename more items from nitb to bscNeels Hofmeyr1-1/+1
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
2017-05-29rename resource nitb_iface to ip_addressNeels Hofmeyr1-1/+1
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: type: public - addr: type: loopback This way we can substitute public vs loopback addresses flexibly (e.g. using scenarios). Change-Id: I3ad583ae7a33f7a7bb56fe78a125f73c56a0e860
2017-05-25resources.conf: remove unused example BTSNeels Hofmeyr1-17/+0
Change-Id: I370789a4dc048cf71c1951f2eb70bfec261583a2
2017-05-11paths: have one common parent dir /var/tmp/osmo-gsm-testerNeels Hofmeyr1-1/+1
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
2017-05-08defaults.conf: use only TCH/F instead of dynamic channelsNeels Hofmeyr1-6/+6
Let's opt for the oldest/simplest case by default. Change-Id: I89d634cc51e13bdf6ec157ffb64baa80a469f4c8
2017-05-05resources: Fix path for gobi_3Pau Espin Pedrol1-1/+1
Change-Id: I10e5e56b6bec6c0b25db15af75d4cbd60fbbc7d9
2017-05-04move /example/suites to /suitesNeels Hofmeyr3-38/+1
/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
2017-05-04put the example suite in /example, not /selftest/real_suiteNeels Hofmeyr10-0/+186
Also drop the env file and tweak the README.txt Change-Id: Ieea274dfd6756498b760c18a5852398cfa396b50