The remsim_client code already used FSMs for the connections
to both remsim-server and remsim-bankd. However the 'main' part of the
program was not yet implemented as a FSM, making it somewhat difficult
to perform the right actions in every possible situation.
This commit re-structures the code around a central main_fsm, which
gets notified from the per-connection FSMs and which handles the common
processing. It also handles the execution of external script commands,
and hence further unifies the code base between the different backends
(simtrace2, ifd_handler, shell)
Closes: #4414
Change-Id: I44a430bc5674dea00ed72a0b28729ac8bcb4e022
This will be useful once we introduce a 'main' client FSM that is a
parent to the rspro_client_fsms.
Change-Id: Ifddb8e0b5c991e5348392c9e44612669ce207bc4
libosmo-abis 0.8.0 has deprecated ipa_client_conn_create() and this
follow-up patch avoids the related deprecation compiler warnings.
Change-Id: I0057c5b6a79e7226e87983c14eb2b0ed2af2a131
This is in preparation of other patches which will actually issue the
SRVC_E_DISCONNET event towards this FSM.
Related: OS#4399
Change-Id: I080f9e85987bbbe7aef84c32ce84b69d949ff561
As both the bankd and the server already are in src/bankd and
src/server, respectively: Let's unify this and have the client
also in its own sub-directory.
Change-Id: I67a3a5941434f09f7099c2cdb19c126cea305a73
We cannot rely on the implicit IPA keepalive FSM termination, as that
somehow gets the termination order wrong and we end up accessing free'd
memory.
Let's handle the termination explicitly: We register a callback with
the IPA keepalive FSM, and once that callback gets hit, we ask the
core to *not* terminate the FSM implicitly. We are anyway terminating
it explicitly in st_reestablish_onenter().
Change-Id: Ia745ccb44c0d0224d1e7ab6b6da3713474111d41
rspro_client_fsm.c:180:9: warning: ‘rc’ may be used uninitialized in this function [-Wmaybe-uninitialized]
180 | return rc;
| ^~
Change-Id: I64b275b06b2aa40bd7c6e1dd42afba5ffebd7b00
Since Change-Id I55d5d61922053fd94e2b5a8cdf0d799b29feec98,
rspro_dec_msg() is no longer taking ownership of the msgb.
Change-Id: Ic1e9f35a2ae82b28dbb4b2ba850c257fa9629cbf
This way we can easily guarantee that RSPRO transmit will only happen
in the fully established state, and that violations of that rule will
generate error logs by means of osmo_fsm core logging code.
Change-Id: I3c403507fa11c068d7503107857fbd5676ce135f
So far, the rspor_client_fsm immediately attempted to establish a
TCP connection to the RSPRO server when calling server_conn_fsm_alloc().
Let's make this implicit auto-connect an explicit request to connect
using the newly-introduced SRVC_E_ESTABLISH.
Let's also change all three existing users of server_conn_fsm_alloc()
to send SRVC_E_ESTABLISH after calling it.
The rationale of this change is to use the same rspro_client_fsm also
for the client->bankd RSPRO connection, where we don't want to
automatically connect at startup, but connect only at a later point, after the
server a has told us to do so.
Change-Id: Icd882405f2ef54e10a66054829c089e4985f1d1f
Initially it seemed like a good idea that rspro_dec_msg() takes care
of freeing the input msgb when generating a new decoded output
structure. However, in reality this made the implementation of
every caller more complicated, as it had to treat messages going into
rspro_dec_msg() differently than messages going elsewhere.
Adding to that, not every caller got it right, and the comments were
disagreeing about what happens to msgb ownership in erroneous cases.
Change-Id: I55d5d61922053fd94e2b5a8cdf0d799b29feec98
We basically must ensure that all code paths *except* the path leading
to rspro_dec_msg() must call msgb_free(msg). This was not the case
in two situations, as fixed now.
Change-Id: I29f8413bb43b3ebf827be0bceda1a4db1e6e2b7c
respro_dec_msg() takes ownership of the input msgb in both
successful and unsuccessful cases, so we must not call talloc_free
on the resulting msgb.
Change-Id: Id54d1b73395da1329a998d213c190da49eb90a93
"remsim-client" is the client program running next to a phone/modem
which is attaching to the SIM slot.
"RSPRO client" is a protocl-level client of the RSPRO protocol:
* the remsim-client connects as RSPRO client to the remsim-server
* the remsim-client connects as RSPRO client to the remsim-bankd
* the remsim-bankd connects as RSPRO client to the remsim-server
Let's clarify this in naming.
Change-Id: I10462d4669a0a30c46f3f8d3df67e9c1d4ce8c4b