There was a lot of similarity between the bankd_client_fsm (for the
client->bankd RSPRO connection) and the rspro_client_fsm (for the
client->server and the bankd->server RSPRO connections).
With the last few commits introducing the missing features to
rspro_client_fsm, we can completely obsolete bankd_client_fsm and
further simplify the codebase.
Change-Id: Icbe9881a0391fcd0c47e5d930dc764fc0cb1dfbf
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
In Change-Id I77c86455f9c36c16271bc8e7f8f3f72d682d23fd for some
reason libosmo-rspro0.install was not renamed/moved but deleted,
causing failures to build debian packages
Change-Id: I825d70abbbd067955d7038377692beea87545ce0
These commands are introduced to enable the server to request the
full reset of all state in a client or bankd. This is particularly
useful in TTCN-3 tests, where we typically want to reset the state
between tests.
Change-Id: I442bab523486bbdf2faa8028f8972cd0af795303
Otherwise the loop for SIGMAPDEL delivery code will match any
unused worker for bank_id=0/slot_nr=0, which is not what we want.
This also makes repeated RemsimBankd_Tests.TC_removeMapping_connected
runs work reliably.
Change-Id: I6976eb96feae6a3b66bacf787e436a2df29f9ce0
It's a bit of a matter of taste whether we should simply log + ignore
if the Client of a removeMappingReq doesn't match what the bankd
currently has configured. I chose to reject it, as a new createMapping
for the same bandk+slot will overwrite any existing mapping anyway,
at least as of I83e319d22896b881c0d882542842f500075aa546
Change-Id: I892282821f4650614d1d08ed4bdf11eaabf947c0
As explained in OS#4278, a remsim-bankd currently doesn't recover after
a remsim-server resetart, since old mappings remain in the bankd, and
the server has no chance of removing them.
To avoid this problem, a createMapping now always implicitly removes
any existing mapping that may exist for the given bankdSlot.
Change-Id: I83e319d22896b881c0d882542842f500075aa546
Closes: OS#4278
It is customary in the IPA protocol that a a server side
responds with an ID_ACK if the client sends an ID_ACK. Due
to the lack of any protocol specification, it's unclear why
exactly, but we know it does happen.
osmo-remsim-bankd so far failed to implement this, which is
not directly a problem as the only user (osmo-remsim-client)
didn't care. However, when executing TTCN3 test cases,
the IPA_Emulation expects that ID_ACK and related test fail.
Change-Id: Ie55c9d5c435df786e97ec3900837bb21ab80140a
ipa_client_conn_destroy() really only destroys the object, but not close
the underlying file descriptor. This leads to old connections
lingering around, which in turn (in case of the remsim client) will
occupy banksim worker threads.
Change-Id: If87f4bbc133e4dc812fa96a75e8495bad65275aa
for the osmo-remsim-client-st2 client,
the command line arguments bankd-port and slot-nr have been renamed
to server-port and client-slot in the opts options, but not in the
help output.
this is now fixed.
Change-Id: Ie23fdc443f2f90f4baf36f8aca237c9994cce8ad
currently the bankId, clientId, and slotNr are passed as strings.
this is not the format expected by the server, which returns 400
"Bad Request".
the issue was that the python tool did not parse the arguments as
integer.
Change-Id: I8baab1b516067f47a7d230213e44d8f85e6d9919
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
We need to unconditionally free the msgb that gets handed into
sock_read_cb() by the ipa server.
Closes: OS#4096
Change-Id: I12b4a22854eea79c9e9c3e565dd4803e4dc0ed5a
Harald Welte
Kevin Redon
Joachim Steiger
Martin Hauke
Oliver Smith