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 https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170419/602c2e3c/attachment.bin>