MS driver: GSM tester config integration

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at

Neels Hofmeyr nhofmeyr at
Tue Mar 6 11:32:23 UTC 2018

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 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <>

More information about the baseband-devel mailing list