Control interface introspection of FSMs
laforge at gnumonks.org
Sun Apr 16 17:40:44 UTC 2017
Good News, everyone [tm]
Some may have already played with it: The osmo_fsm's already have gained
a VTY interface (see
http://git.osmocom.org/libosmocore/tree/src/vty/fsm_vty.c) some time
ago, which is nice for manual debugging and the like.
However, for automatic testing one would normally want to do something
like the following:
1) send a packet to the implementation under test (IUT)
2) then check if a given FSM has been created, a state has changed,
a timer is running, etc.
3) go to '1' for the next packet, or wait for a timeout and then
I've just introduced a generic CTRL interface for programmatic access to
osmo_fsm. See https://gerrit.osmocom.org/#/c/2377 for details.
The general idea is that you can send a CTRL command like
GET 1 fsm.FSM_NAME.id.INSTANCE_ID.state
GET 1 fsm.FSM_NAME.id.INSTANCE_ID.timer
GET 1 fsm.FSM_NAME.id.INSTANCE_ID.parent-name
GET 1 fsm.FSM_NAME.id.INSTANCE_ID.dump
Where FSM_NAME is the name of the osmo_fsm (class) and INSTANCE_ID is
the identity of the instance (e.g. the IMSI of a subscriber in the VLR
So in OsmoMSC, something like
GET 1 fsm.vlr_lu_fsm.id.901700123456789.state
would return the string name of the state for the location update FSM of
the given IMSI, e.g. "VLR_ULA_S_WAIT_LU_COMPL_STANDALONE"
I presume Neels will like this. Could be used from osmo-gsm-tester to
not just do "black box testing" from MS to MS or MS to MNCC, but to
actually verify individual states/transitions on all osmo_fsm enabled
elements. It's of course questionable if an end-to-end test should
care, but I can think of all kinds of other testing (particularly of my
new SIGTRAN work) where it is absolutely useful.
Once the above-mentioned patches are merged, applications with a control
inteface will have this functionality enabled automatically. I think
this makes osmo_fsm even more useful. I can imagine use cases not only
related to testing, but also use cases of e.g. user interfaces or
p.s.: In German we say "self praise stinks", but I really think osmo_fsm
is one of the best things happening to the Osmocom cellular projects in
recent years. Now we just need to convert more code to use it.
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
More information about the OpenBSC