Hey,
pespin left a good comment about the question of how the MS driver and the GSM tester could be better integrated. I was about to write some argparse code for the MS driver but I think it is best to make this configurable as a scenario.
In terms of scenario knobs I can see:
- #MS - CDF function - IMSI generator (start with XXX and count upwards) - virtphy vs. trxcon?
The actual test would remain separate (and maybe turn it into a suite at some point in the future). What do you think? What should I obey when parsing/handling config?
holger
On Mon, Mar 05, 2018 at 11:28:49PM +0000, Holger Freyther wrote:
Hey,
pespin left a good comment about the question of how the MS driver and the GSM tester could be better integrated. I was about to write some argparse code for the MS driver but I think it is best to make this configurable as a scenario.
In terms of scenario knobs I can see:
- #MS
- CDF function
what's CDF?
- IMSI generator (start with XXX and count upwards)
We have MSISDN and I think LAC generated on-the-fly, with state in the file system. You could basically copy-paste that MSISDN generator code to make an IMSI generator.
- virtphy vs. trxcon?
(no idea)
The actual test would remain separate (and maybe turn it into a suite at some point in the future). What do you think? What should I obey when parsing/handling config?
The way I see it, you implement a "copy" of the mobile.py interface to, instead of talking to ofono, talk to the virtphy/MS, whatever it's called. (Like Pau said.)
Then either:
- We define a limited specific number of those virtual modems in the resources.conf to be available, and add a specific trait, as in a 'type: virtual' or something. You would then add a scenario that asks for the modems to be of 'type: virtual', and run the exact tests from the existing suites, just with virtual modems instead of physical ones.
- Or we could even auto-generate the entire virtual modem, sort of in the way that we start core net components at the moment, by calling a function from within the test case. For example, the osmo-msc is not a resource handled in scenarios, we just ask for IP address resources and hand one to the osmo-msc startup. Then there would be a separate *suite* with its conf not even asking for any modem resources, just its tests call a function that ask to setup virtual modems on-the-fly. A drawback here is that you can't just re-run existing suites -- you can't just swap out the physical modem kind for a virtual one and run the exact same suite, you have to write different tests that launch virtual modems from the test case script.
It depends on: a) do you want to run the existing tests on the virtual modems at all? b) how physical/resource-like vs. software-component-running-like is a virtual modem?
For virtual modem being a resource, I'd add only separate scenario definitions and possibly add tests to existing suites if that makes any sense; for virtual modems started up like a software component, I'd add an entirely separate suite even for the first test implemented (because then that suite wouldn't ask for 'modem' resources to begin with).
BTW, in general, a virtphy issue could be the multicast. I saw stsp having some trouble keeping the multicast from seeping out of all the interfaces. We probably want the osmo-gsm-tester to contain that somehow.
~N
Hi,
I guess you are referring to my comment in [1]. You can reuse suite and resources management utilities already present in osmo-gsm-tester. The easiest way to do that would be to create a new implementation for class Modem which would start a mobile process underneath. Then in suite() when requesting a modem add a function to allocate class ModemOfono or ModemOsmoMobile based on config type, similar to how it is done for different bts (see example/resources.conf and src/osmo_gsm_tester/suite.py).
Then, you have your resources files with 300 modems: modem: - label: mobile_xyz type: osmo-mobile auth_algo: 'comp128v1' ciphers: [a5_0, a5_1] features: ['sms', 'voice', 'ussd', 'gprs'] times: 300
Then create a suite with a suite.conf containing your scenario (see suites/aoip_sms/suite.conf): resources: ip_address: - times: 6 # msc, bsc, hlr, stp, mgw*2 bts: - times: 1 modem: - times: 300 features: - sms
Then, create a test which manages all those (see suites/aoip_sms/mo_mt_sms.py): #!/usr/bin/env python3 from osmo_gsm_tester.testenv import * while True: modems = [] try: # we could add a suite.get_num_resources(type='modem') API instead m = suite.modem() modems.append(m) except NoResourceExn: break; # Then do here whatever you like to do with them, like register them, etc.
I think that CDF functions and IMSI generation and alike are really attach to the test and they are really not resources, so no need to "configure" them. This topic matches with your other mail thread too. We already talked with Neels about providing a set of functionality helpers and repeating code used in tests, in order to keep tests small and easy to follow. My bet here would be to have code like CDF functions which is not used internally by osmo-gsm-tester classes into this kind of library (which can be imported like from osmo_gsm_tester.testenv import *). Same goes for IMSI generation, then use modem.set_imsi(generated_imsi) or whatever before calling modem.connect(). If you want to avoid IMSI collision between consecutive tests, then add it to osmo-gsm-tester resource.py (see next_lac() for instance).
About using virtphy, trxcon and all these stuff, we have the problem that the ARFCN config is still not completely arranged and implemented. I arrived to some good proposal after several patch revision with Neels, which can be found in [2], but still missing the actual implementation. The idea I have in mind would be to add an extra attribute to arfcn resources called "group" which allows to have separate groups of arfcn, for instance phy-air vs virt, but also phy-dn1 vs phy-dn2 in case we have several non colliding distributions networks (Distributed network = MS and BTS connected through wires). Then each resource playing with arfcn should have the attribute "arfcn-group: xyz" to know to which arfcn medium is it connected. This will be used by the algorithm in [2] to manage arfcn correctly or error if the combination specificed in the scenario is not possible (for instance explicitly requesting a phy BTS but only having virtphy MS).
We could Add DistributionNetwork class if needed, which could be accessed and started from the different objects using them, like ms.dn() or bts.dn().
[1] https://gerrit.osmocom.org/#/c/6919/ [2] https://osmocom.org/issues/2230
On 6. Mar 2018, at 12:20, Pau Espin Pedrol pespin@sysmocom.de wrote:
Hi,
Hey Neels, Pau,
I guess you are referring to my comment in [1]. You can reuse suite and resources management utilities already present in osmo-gsm-tester. The easiest way to do that would be to create a new implementation for class Modem which would start a mobile process underneath. Then in suite() when requesting a modem add a function to allocate class ModemOfono or ModemOsmoMobile based on config type, similar to how it is done for different bts (see example/resources.conf and src/osmo_gsm_tester/suite.py).
thanks to both of you for the detailed responses. I like the idea, it solves the coordination between setting up the core network and the phones. The approach looks generally feasible and I wish we had this idea earlier.
Unfortunately I had only planned to do LUA bindings, the orchestration was already an extra and I blew all my time in trying to make asyncio work and the scaling/concurrency issues with python. My intention with the original mail was to find a middle step. Better integration but not full.
From my point of view:
Middle step:
Use the test scenario configuration (maybe even the suite class).
Make the UL test reusable (and extend to SMS and Calls)
Big step (as proposed):
The "scheduling"/slow start is not like any of the existing tests (there are conceptual difference of fail/pass handling when launching 10k procs)
The event loops need to be integrated. Not sure how to integrate this with glib loop for glib-dbus?
A base class for a MS (or ME) without being ofono specific and simple enough. Currently the lua JSON code is only from MS->Test.
Need to add primitive to register a FD so lua can get an answer back.
Find a way to set SO_PASSCRED on the socket to have "mobile" reachable by the event server as well. Could be a lua binding or we patch lua socket
Have a lua script that forwards the "on/off", "limit to cell XYZ", "Send SMS", "Place Call", "Open Call and read data from this socket"
Missing primitives for mobile. But we need them anyway.
The middle step is in-reach, the big step will take some real time and I could use some help (e.g. the event loop integration).
I think that CDF functions and IMSI generation and alike are really attach to the test and they are really not resources, so no need to "configure" them. This topic matches with your other mail thread too.
The "SIM" card would need to be in the device so IMSI kind of belongs to the resource?
Hi Holger,
thanks to both of you for the detailed responses. I like the idea, it solves the coordination between setting up the core network and the phones. The approach looks generally feasible and I wish we had this idea earlier.
Unfortunately I had only planned to do LUA bindings, the orchestration was already an extra and I blew all my time in trying to make asyncio work and the scaling/concurrency issues with python. My intention with the original mail was to find a middle step. Better integration but not full.
I know some of the concepts in osmo-gsm-tester are quite complex to grasp (lots of specific stuff like scenarios, resources, etc.), and some of the required stuff is still missing (like better poll loop, managing arfcns, etc. we have tasks created for them). As it's quite a bit amount of work and it was not your primary focus, I don't expect to have everything done in one step. Merging it as a separate env then slowly moving it into osmo-gsm-tester seems fine for me. Personally I was also lacking a better understanding on how mobile operates and the resulting work of the lua bindings, as I didn't play with it yet. Seeing your patches helped me a lot understanding better what is there and where can we go from this first step.
Middle step:
Use the test scenario configuration (maybe even the suite class).
Make the UL test reusable (and extend to SMS and Calls)
What do you mean with reusable here? Can you explain it a bit more? Do you mean being able to use other Modem implementations? I agree with that.
Big step (as proposed):
The "scheduling"/slow start is not like any of the existing tests (there are conceptual difference of fail/pass handling when launching 10k procs)
The event loops need to be integrated. Not sure how to integrate this with glib loop for glib-dbus?
I think the best would be having our own loop, which then also polls glib loop in the process. As far as I remember glib provides APIs to get poll notifications (via fd?) in case an event from them is triggered. If I recall correctly EFL libs have APIs to do that for apps which want to run efl+glib at the same time.Probably Qt guys do the same.
Other possibility would be to have our own loop which is internally implemented using glib one.
Having a better loop was not a hard requirement until now because we were fine without fine-grained time lapses and just active polling every 0.1 seconds, but I'd really like having a better loop.
I'll try to find some time in next days to have a look at improving the current event loop.
A base class for a MS (or ME) without being ofono specific and simple enough. Currently the lua JSON code is only from MS->Test.
I can help you with that, given that you provide all the lua specific parts.
The "SIM" card would need to be in the device so IMSI kind of belongs to the resource?
An IMSI belongs to the resource, but the generator itself can be used in different tests. The IMSI field in the Modem resource is there for historical reasons (for instance if you'd like to force a specific IMSI by default), but we should rework ModemOfono to get the IMSI from ofono/dbus instead, since we are finally not using the IMSI to identify the modems but its sysfs path.
baseband-devel@lists.osmocom.org
-
Holger Freyther -
Neels Hofmeyr -
Pau Espin Pedrol