19 Apr
2017
19 Apr
'17
2:14 p.m.
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:
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
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