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