6 Mar
2018
6 Mar
'18
12:28 a.m.
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
6 Mar
6 Mar
12:32 p.m.
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
1:20 p.m.
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
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
7 Mar
7 Mar
5:37 p.m.
On 6. Mar 2018, at 12:20, Pau Espin Pedrol
<pespin(a)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?
6:22 p.m.
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.
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
2244
days inactive
2246
days old
4 comments
3 participants
participants (3)
-
Holger Freyther -
Neels Hofmeyr -
Pau Espin Pedrol