cellular-infrastructure
/
osmo-gsm-tester
mirror of https://gerrit.osmocom.org/osmo-gsm-tester
9
0
Fork 0
Code Issues Releases Wiki Activity
osmo-gsm-tester/example/resources.conf

99 lines
1.8 KiB
Plaintext
Raw Normal View History

initial import The original osmo-gsm-tester was an internal development at sysmocom, mostly by D. Laszlo Sitzer <dlsitzer@sysmocom.de>, of which this public osmo-gsm-tester is a refactoring / rewrite. This imports an early state of the refactoring and is not functional yet. Bits from the earlier osmo-gsm-tester will be added as needed. The earlier commit history is not imported.
2017-03-28 10:16:58 +00:00
# all hardware and interfaces available to this osmo-gsm-tester
rename resource nitb_iface to ip_address 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
2017-05-18 16:35:32 +00:00
ip_address:
trying to get sysmobts to work and various details I know that these commit messages aren't very good, but the code is not stable yet, so I'm not bothering with details. Change-Id: I2d5e5f4a5407725d71093cbd71ef97b271eb8197
2017-04-10 01:45:30 +00:00
- addr: 10.42.42.2
- addr: 10.42.42.3
resources.conf: more IP addresses 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-22 17:58:06 +00:00
- addr: 10.42.42.4
- addr: 10.42.42.5
- addr: 10.42.42.6
Require OsmoMgw in OsmoBsc and update tests 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
2017-11-09 12:02:09 +00:00
- addr: 10.42.42.7
initial import The original osmo-gsm-tester was an internal development at sysmocom, mostly by D. Laszlo Sitzer <dlsitzer@sysmocom.de>, of which this public osmo-gsm-tester is a refactoring / rewrite. This imports an early state of the refactoring and is not functional yet. Bits from the earlier osmo-gsm-tester will be added as needed. The earlier commit history is not imported.
2017-03-28 10:16:58 +00:00
bts:
- label: sysmoBTS 1002
fix octphy, fix conf, improve logging Clearly separate the kinds of BTS hardware the GSM tester knows ('type') from the NITB's bts/type config item ('osmobsc_bts_type' -- not 'osmonitb_...' to stay in tune with future developments: it is the libbsc that needs this). For BTS hardware kinds, use the full name of the binary for osmo driven models: osmo-bts-sysmo, osmo-bts-trx, osmo-bts-octphy. Change-Id: I1aa9b48e74013a93f9db1a34730f17717fb3b36c
2017-04-13 01:11:59 +00:00
type: osmo-bts-sysmo
octphy (untested); fix regression test expectations Change-Id: Ie9986e0fe49171fb616ce92c3d8652002318f94f
2017-04-12 00:42:02 +00:00
ipa_unit_id: 1
initial import The original osmo-gsm-tester was an internal development at sysmocom, mostly by D. Laszlo Sitzer <dlsitzer@sysmocom.de>, of which this public osmo-gsm-tester is a refactoring / rewrite. This imports an early state of the refactoring and is not functional yet. Bits from the earlier osmo-gsm-tester will be added as needed. The earlier commit history is not imported.
2017-03-28 10:16:58 +00:00
addr: 10.42.42.114
core implementation code bomb implementing the bulk of the osmo-gsm-tester Change-Id: I53610becbf643ed51b90cfd9debc6992fe211ec9
2017-03-28 12:30:28 +00:00
band: GSM-1800
OsmoPcuSysmo: Integrate with Sysmobts and OsmoSgsn Change-Id: I01485c5d74e5fe62d0ffea9eb1fad29041426eef
2017-11-23 10:01:24 +00:00
direct_pcu: true
Add cipher cfg param for modem and bts 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-08-28 12:21:15 +00:00
ciphers: [a5_0, a5_1, a5_3]
initial import The original osmo-gsm-tester was an internal development at sysmocom, mostly by D. Laszlo Sitzer <dlsitzer@sysmocom.de>, of which this public osmo-gsm-tester is a refactoring / rewrite. This imports an early state of the refactoring and is not functional yet. Bits from the earlier osmo-gsm-tester will be added as needed. The earlier commit history is not imported.
2017-03-28 10:16:58 +00:00
Add scenarios for each osmo-bts-trx type 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-23 12:49:07 +00:00
- label: Ettus B200
fix octphy, fix conf, improve logging Clearly separate the kinds of BTS hardware the GSM tester knows ('type') from the NITB's bts/type config item ('osmobsc_bts_type' -- not 'osmonitb_...' to stay in tune with future developments: it is the libbsc that needs this). For BTS hardware kinds, use the full name of the binary for osmo driven models: osmo-bts-sysmo, osmo-bts-trx, osmo-bts-octphy. Change-Id: I1aa9b48e74013a93f9db1a34730f17717fb3b36c
2017-04-13 01:11:59 +00:00
type: osmo-bts-trx
octphy (untested); fix regression test expectations Change-Id: Ie9986e0fe49171fb616ce92c3d8652002318f94f
2017-04-12 00:42:02 +00:00
ipa_unit_id: 6
bts_osmotrx: Support configuring bts addr, trx_remote_ip and launch_trx 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
2017-08-22 09:17:43 +00:00
addr: 10.42.42.50
core implementation code bomb implementing the bulk of the osmo-gsm-tester Change-Id: I53610becbf643ed51b90cfd9debc6992fe211ec9
2017-03-28 12:30:28 +00:00
band: GSM-1800
bts_osmotrx: Support configuring bts addr, trx_remote_ip and launch_trx 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
2017-08-22 09:17:43 +00:00
launch_trx: true
Add cipher cfg param for modem and bts 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-08-28 12:21:15 +00:00
ciphers: [a5_0, a5_1]
bts_osmotrx: Support configuring bts addr, trx_remote_ip and launch_trx 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
2017-08-22 09:17:43 +00:00
- label: sysmoCell 5000
type: osmo-bts-trx
ipa_unit_id: 7
addr: 10.42.42.51
band: GSM-1800
trx_remote_ip: 10.42.42.112
Add cipher cfg param for modem and bts 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-08-28 12:21:15 +00:00
ciphers: [a5_0, a5_1]
initial import The original osmo-gsm-tester was an internal development at sysmocom, mostly by D. Laszlo Sitzer <dlsitzer@sysmocom.de>, of which this public osmo-gsm-tester is a refactoring / rewrite. This imports an early state of the refactoring and is not functional yet. Bits from the earlier osmo-gsm-tester will be added as needed. The earlier commit history is not imported.
2017-03-28 10:16:58 +00:00
Add support for osmo-bts-octphy 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
2017-09-15 12:11:35 +00:00
- label: OCTBTS 3500
type: osmo-bts-octphy
ipa_unit_id: 8
addr: 10.42.42.52
band: GSM-1800
trx_list:
- hw_addr: 00:0c:90:2e:80:1e
net_device: eth1
initial import The original osmo-gsm-tester was an internal development at sysmocom, mostly by D. Laszlo Sitzer <dlsitzer@sysmocom.de>, of which this public osmo-gsm-tester is a refactoring / rewrite. This imports an early state of the refactoring and is not functional yet. Bits from the earlier osmo-gsm-tester will be added as needed. The earlier commit history is not imported.
2017-03-28 10:16:58 +00:00
arfcn:
core implementation code bomb implementing the bulk of the osmo-gsm-tester Change-Id: I53610becbf643ed51b90cfd9debc6992fe211ec9
2017-03-28 12:30:28 +00:00
- arfcn: 512
band: GSM-1800
- arfcn: 514
band: GSM-1800
- arfcn: 516
band: GSM-1800
- arfcn: 518
band: GSM-1800
- arfcn: 520
band: GSM-1800
- arfcn: 540
band: GSM-1900
- arfcn: 542
band: GSM-1900
- arfcn: 544
band: GSM-1900
- arfcn: 546
band: GSM-1900
- arfcn: 548
band: GSM-1900
initial import The original osmo-gsm-tester was an internal development at sysmocom, mostly by D. Laszlo Sitzer <dlsitzer@sysmocom.de>, of which this public osmo-gsm-tester is a refactoring / rewrite. This imports an early state of the refactoring and is not functional yet. Bits from the earlier osmo-gsm-tester will be added as needed. The earlier commit history is not imported.
2017-03-28 10:16:58 +00:00
modem:
resources.conf: configure sierra modems
2017-05-02 12:41:36 +00:00
- label: sierra_1
path: '/sierra_1'
imsi: '901700000009031'
ki: '80A37E6FDEA931EAC92FFA5F671EFEAD'
Introduce auth_algo modem config attribute 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-24 14:57:17 +00:00
auth_algo: 'xor'
Add cipher cfg param for modem and bts 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-08-28 12:21:15 +00:00
ciphers: [a5_0, a5_1]
Add minimal USSD support to test extension number Change-Id: Ib19331f9c6476ac01bf729790dfd63c56de86a89
2017-06-12 13:31:27 +00:00
features: ['sms', 'voice', 'ussd']
resources.conf: configure sierra modems
2017-05-02 12:41:36 +00:00
- label: sierra_2
path: '/sierra_2'
imsi: '901700000009029'
ki: '00969E283349D354A8239E877F2E0866'
Introduce auth_algo modem config attribute 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-24 14:57:17 +00:00
auth_algo: 'xor'
Add cipher cfg param for modem and bts 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-08-28 12:21:15 +00:00
ciphers: [a5_0, a5_1]
Add minimal USSD support to test extension number Change-Id: Ib19331f9c6476ac01bf729790dfd63c56de86a89
2017-06-12 13:31:27 +00:00
features: ['sms', 'voice', 'ussd']
resources.conf: configure sierra modems
2017-05-02 12:41:36 +00:00
- label: gobi_0
path: '/gobi_0'
imsi: '901700000009030'
ki: 'BB70807226393CDBAC8DD3439FF54252'
Introduce auth_algo modem config attribute 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-24 14:57:17 +00:00
auth_algo: 'xor'
Add cipher cfg param for modem and bts 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-08-28 12:21:15 +00:00
ciphers: [a5_0, a5_1]
resources.conf: Add gprs feature for EC20 modem Change-Id: I99a1e8c2fbd3856f5c1978449292871498c6bf18
2017-11-20 18:53:05 +00:00
features: ['sms', 'ussd', 'gprs']
resources: update modems, sierra_3 replaced by a Gobi Change-Id: I95832920a83ede29f314dfce23e1089729dcf3c7
2017-05-03 14:39:09 +00:00
- label: gobi_3
resources: Fix path for gobi_3 Change-Id: I10e5e56b6bec6c0b25db15af75d4cbd60fbbc7d9
2017-05-05 14:02:28 +00:00
path: '/gobi_3'
resources: update modems, sierra_3 replaced by a Gobi Change-Id: I95832920a83ede29f314dfce23e1089729dcf3c7
2017-05-03 14:39:09 +00:00
imsi: '901700000009032'
ki: '2F70DCA43C45ACB97E947FDD0C7CA30A'
Introduce auth_algo modem config attribute 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-24 14:57:17 +00:00
auth_algo: 'xor'
Add cipher cfg param for modem and bts 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-08-28 12:21:15 +00:00
ciphers: [a5_0, a5_1]
Add features attribute to modems 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-08-31 16:49:47 +00:00
features: ['gprs']