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 re-check, ...
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 code).
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 visualization.
Regards, Harald
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.
On Sun, Apr 16, 2017 at 07:40:44PM +0200, Harald Welte wrote:
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:
- send a packet to the implementation under test (IUT)
- then check if a given FSM has been created, a state has changed, a timer is running, etc.
- go to '1' for the next packet, or wait for a timeout and then re-check, ...
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 code).
So in OsmoMSC, something like
GET 1 fsm.vlr_lu_fsm.id.901700123456789.state
Nice! Could become useful once we move to OsmoMSC on the gsm tester (so far still the old/aging OsmoNITB without a VLR is run there). Currently the tester uses ctrl subscriber-list-active to verify attached-ness.
Notably, FSMs like this one (vlr_lu_fsm) exist for a very limited amount of time. Once a LU is through (success or failure), the FSM instance is deallocated. A vlr_lu_fsm or parq_fsm will be active while an authentication is ongoing, e.g. if the OsmoHLR has not replied with an auth tuple yet. But during normal operation, FSMs will be gone quite quickly.
The longest living one is the conn_fsm, it exists while a subscriber connection is active, so it may make sense to query it while a voice call is active. But it could be hard for a test case to catch even the conn_fsm before it is gone for things like sending an SMS or running a USSD. When a subscriber is attached but has no active connections, there are no FSM instances in the VLR, only a flag set in the vlr_subscriber struct.
And furthermore, the FSM's id isn't always clear: it will use the mobile identity that came with the first request -- if e.g. a LU came in by previously known TMSI, and then the TMSI gets reallocated, the FSM will still use the old TMSI as identification. I had plans to update the id once things become known, also to improve log readability, but so far it's just using the first identity that comes up.
~N
-
Harald Welte -
Neels Hofmeyr