| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The event case handling (ignore it) was added in a commit some time ago,
but it forgot to add it to the allstate_event_mask in the xua_fsm (it
was added only in the ipa_fsm, which is the one using it).
This bug should in theory be harmless since the only code dispatching
the signal is not checking the return code of osmo_fsm_inst_dispatch().
Related: SYS#5914
Fixes: 57444690212b1576eaf0a7156448ba2d27c59050
Change-Id: Iaead46bbc40b923763bc3dbe4d24d8952822de4a
|
|
The LOGPFSML() prints current state of an ASP FSM instance,
which is useful for debugging.
Change-Id: I28f3f89a8158bbedc224922a6ec151b1bbd6c7c0
|
|
We've always been logging received MGMT:ERR messages, but we somehow
didn't log the transmission of them. So whenever osmo-stp generates
some error to a connected peer, the peer would show it, but not osmo-stp
itself. Let's fix that.
Change-Id: I50c05409646fd47e70d904fb95bbc2fa15703b3e
|
|
A recent patch fixed a long problem where the ASP name (instead of
expected AS name) was used as ipa_unit_name in IPA based ASPs.
For server side it doesn't matter much, sense anyway the ipa_unit_name
is actually restored on the struct with what's received in IPA GET_RESP
message (see ipa_asp_fsm_wait_id_resp()). So the fix was actually for
the client side in the scenario where a non-dynamic ASP with an assigned
AS was configured in the VTY.
However, dynamic ASPs usually have no assigned AS (because in general it
is really not created/configured, as the ASP is created on the flight).
As a result, the recent patch (see "Fixes" below), broke dynamic ASPs
case because from then one ipa_asp_fsm_start() would fail and terminate
the FSM because ipa_find_as_for_asp() was returning NULL.
So improve the recent patch by applying the previous logic for dynamic
ASPs:
* On the server side, it really doesn't matter since as mentioned, the
field will be repopulated later on, but allows the code to avoid
terminating the FSM and hence be brought up and be ready to receive
clients.
* On the client case, this is how dynamic IPA ASPs were ment to be used
when they were introduced anyway (use ASP as ipa_unit_id, meaning
"AS name" == "ASP name").
Furthermore, on the client side, the non-dynamic IPA ASPs need their
bring up be delayed until assigned to an AS, because the AS name is sent
in ipa_unit_name field in Tx IPA ID RESP.
This usually happens at a later point than ASP (FSM) creation, because
first the ASP object is created (through VTY or API) and then assigned
to an AS through osmo_ss7_as_add_asp() usually from a later "asp" vty
command in the "as" node.
Fixes: 65741dca056e3a16973ad156dd4c09760a6a945b
Change-Id: I0a741449450c998253b1e44a76a3b7fc224e0903
Related: SYS#5914
|
|
Change-Id: I1c4fe7d1b3a5cdd4c2c9c942e292a7135467d9e2
|
|
This was broken since ever. The client was submitting the ASP name
in the unit_id field during IPA handshake, and the server was
expecting it to contain the AS, so it failed with message:
"Cannot find any definition for IPA Unit Name '%s'" in
ipa_asp_fsm_wait_id_resp().
Fixes: 5f0a8df34cae20455a520c3a85cf94124f486bf2
Change-Id: I249964e171f578726439c40e01ae85aa447afada
|
|
The existing/old osmo_stream_{srv,cli}_get_ofd() API functions are
only compatible with OSMO_FD mode of libosmo-netif/stream. In the
OSMO_IO mode, there is no osmo_fd involved, and hence those functions
are illegal to call.
Let's instead migrate over to the new osmo_stream_{srv,cli}_get_fd()
which directly return the file descriptor integer value.
Change-Id: I12c66badfb4bdfdfe71f1716de960d353d3548b1
Related: OS#5752
|
|
If there is only one routing key (and hence routing context, and hence
AS) within one ASP, *and* the routing context is configured as 0 (zero),
we should not include the routing context IE. This is the way how
libosmo-sigtran has always been special-casing routing context 0 meaning
"routing context is not used". However, that was only working in SG
role (typical STP use case). When operating in ASP role, the
special-case handling was missing, causing a routing context IE
containing zero to be included in the related transmitted M3UA ASPAC
and ASPIA messages.
Change-Id: I5ce89b393a3b950ab7fd1eace9038718c9efcc51
Closes: OS#6003
|
|
As of GCC 11.1.0, it starts printing a warning about uninitialized
variable. It is a false positive since tmode is really only used in the
case where traffic_mode is not zero, in which case tmode is set.
Let's restrict the scope of tmode to fix the issue and also make it
clearer where the variable is used.
"""
In file included from /git/libosmo-sccp/src/xua_asp_fsm.c:25:
/git/libosmo-sccp/src/xua_asp_fsm.c: In function ‘xua_asp_fsm_inactive’:
/git/libosmo-sccp/include/osmocom/sigtran/osmo_ss7.h:274:16: error: ‘tmode’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
274 | return get_value_string(osmo_ss7_as_traffic_mode_vals, mode);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/git/libosmo-sccp/src/xua_asp_fsm.c:476:39: note: ‘tmode’ was declared here
476 | enum osmo_ss7_as_traffic_mode tmode;
|
"""
Change-Id: I4fc38724aba3a3f178ba0b45444e1394db44d039
|
|
The behavior here since to have changed at least a couple times in
history, always apparently breaking some compatibility:
* libosmo-sccp.git a0dd986f5506ee8a625e827bc029d1aa962b6f65
(SCCPLite MSC sends IPA ID ACK at startup) [10th July 2018]
* libosmo-sccp.git 9c0fae14d105b64ec9e8ff7322fa4aca782e54d1
(Reverts back to sending IPA ID GET at startup [29th April 2021]
* osmo-ttcn3-hacks.git 3bf31d216a18c1d6a6e298a592f873beea322939
(Changes server emulation to send IPA ID ACK when BSC connects to it) [24th August 2018)
So it seems the proper way is to start handshake:
CLI <- SRV: IPA ID GET
CLI -> SRV: IPA ID RESP
CLI <- SRV: IPA ID ACK
CLI -> SRV: IPA ID ACK
However, it seems some SCCPLite MSCs (acting as IPA srv) skip the first
ID GET + ID RESP handshake and go directly for ACKs:
CLI <- SRV: IPA ID ACK
CLI -> SRV: IPA ID ACK
So, let's make everybody happy and support both cases in the client FSM.
If server sends us IPA ID ACK first, simply send back an IPA ID ACK and
be done with it, otherwise if it sends us an IPA ID GET, go for the full
handshake.
Change-Id: Ie9968ce8cd8582deb583024ff3e46736a07883fe
|
|
Reorder functions to follow usual order in FSM files:
1- structs and helper functions
2- for each state: first _oneneter, then the action func
3- generic state fsm functions (timers, all_state)
4- struct osmo_fsm_state
5- FSM allocator and public functions
Change-Id: Ic143db3dda48750effddaa0cafadf960f5b5c38c
|
|
The IPA server worked as expected, but the IPA client has some clear
logic bug that prevented it from working. It shows that we never
really use any of that IPA/SCCPlite stuff after years in spec-compliant
SIGTRAN land.
A client now first waits for the IPA_REQ, sends its IPA_RESP, then
waits for the ACK, ...
Change-Id: Icfc32cad7d65c94dc21754b8f879afcf34d34a92
|
|
SS7 routes operate on AS level, not ASP level. However, the
automatic SS7 route creation/destruction for IPA was implemented
at the ASP level. This works for single-connection ASs, but
obviously fails in load-share situations: We attempt to add the
same route several times, and we delete it at the first ASP
disconnect, even while other ASPs still exist.
This patch moves the IPA route creation/deletion from the ASP level
to the AS level. When the AS becomes active, the route is added;
when it goes to DOWN state, it is removed.
Change-Id: Idb602beae3e9bc19f7bd96355c02ec8dfd9c5d6c
|
|
Contrary to proper SIGTRAN, IPA/SCCPlite cannot support multiple
AS within one ASP. When looking up the AS from the ASP, we cannot
blindly use routing context 0 to find the AS, as there may very well
be multiple IPA AS, and all of those have routing context 0.
As a result, the exiting look-up by osmo_ss7_as_find_by_rctx(inst, 0)
will return the wrong AS, and we will try to add/delete routes for
a completely different AS when ASPs are coming up or going down.
Instead, we need to use xua_find_as_for_asp() in order do the look-up:
It will resolve the single AS within the ASP.
Change-Id: Id295daf84f6ba1cc56cbe1761f874bea329e17ea
Cloess: SYS#5422
|
|
Let's inform the user about situations in which we'd want to delete
the route for an IPA client, but we run into some problem and
bail out early.
Change-Id: Ie3f57d22901f169afb2c844476b5839cc36752aa
Related: SYS#5422
|
|
Those values (except for XUA_T_ACK_SEC) are not used at all, and anyway
they already exist as timers in osmo_sccp_timer_defaults (sccp_scoc.c).
Change-Id: Id5902e809e02b2651e381cd58ef97b77c1143dc2
|
|
Change-Id: Ia39d4961a2690ea4c56276db8f1503a75e97d154
|
|
We don't want to attempt to re-transmit if we lost the connection:
DLSS7 <000c> xua_asp_fsm.c:251 XUA_ASP(asp-client0){ASP_DOWN}: T(ack) callback: re-transmitting event ASPSM-ASP_UP
DLSS7 <000c> osmo_ss7.c:1833 0: asp-asp-client0: Cannot transmit, asp->client not connected
DLSS7 <000c> xua_asp_fsm.c:251 XUA_ASP(asp-client0){ASP_DOWN}: T(ack) callback: re-transmitting event ASPSM-ASP_UP
DLSS7 <000c> osmo_ss7.c:1833 0: asp-asp-client0: Cannot transmit, asp->client not connected
DLSS7 <000c> xua_asp_fsm.c:251 XUA_ASP(asp-client0){ASP_DOWN}: T(ack) callback: re-transmitting event ASPSM-ASP_UP
DLSS7 <000c> osmo_ss7.c:1833 0: asp-asp-client0: Cannot transmit, asp->client not connected
DLSS7 <000c> xua_asp_fsm.c:251 XUA_ASP(asp-client0){ASP_DOWN}: T(ack) callback: re-transmitting event ASPSM-ASP_UP
DLSS7 <000c> osmo_ss7.c:1833 0: asp-asp-client0: Cannot transmit, asp->client not connected
DLSS7 <000c> xua_asp_fsm.c:251 XUA_ASP(asp-client0){ASP_DOWN}: T(ack) callback: re-transmitting event ASPSM-ASP_UP
Change-Id: Ic8da646d22d3120121d9af43a890762a879f9d74
|
|
let's avoid messages like
DLSS7 <000c> xua_asp_fsm.c:600 XUA_ASP(asp-client0){ASP_DOWN}: transition to state ASP_DOWN not permitted!
Change-Id: Iabbcf92e3022a4c3f165ce19be929915f92b455c
|
|
If we are running in ASP (client) role, and we are about to transmit an
ASPAC or ASPIA to the SG, we must make sure to include any applicable
routing contexts.
Change-Id: Iee4f0d553d6845a9ae08cb5e4f57fdec443e4ef9
Related: OS#4285
|
|
When a client (ASP) sends an ASPAC to the server (SG), it should include
the traffic-mode configured for it's ASs, if any.
Change-Id: Ia850df22df529dab74959e8666f85976002c482c
Related: OS#4285
|
|
Since there's no official spec for IPA and some
implementations seem to like sending the IPA ID ACK before
the IPA ID RESP, let's catch it and feed it after we receive
the IPA ID RESP and we are in correct state. Otherwise the connection
would deadlock during the initial handshake.
That's the case with our TTCN3 IPA implementation running STP_Tests
suite.
Change-Id: I99f5346a3854ca07979020245897334197f3cd3b
|
|
If AS is configured with Traffic Mode Override, then if a new ASP
becomes active, all previous ASPs are considered to be inactive and new
data is sent to the newly activated ASP.
Remark: It's still unclear which methodology/implementation will follow
when the last activated ASP becomes inactive/shutdown. Then probably
another one should be activated at that time, but that logic is not
there implemented as far as I know.
Change-Id: I4ff246b2f899aaa3cf63bbdb3f3d317dc89b3d15
|
|
This supersedes the library-internal enum xua_asp_role.
Change-Id: I28b0888b8f8206e9dd67ef64ce0f71ba9a7105ce
|
|
If the AS is e.g. configured as broadcast, then individual ASPs cannot
be activated in loadshare or override. Everyone must agree.
Change-Id: Ic73410fbc88d50710202453f759fa132ce14db4c
|
|
Change-Id: I8ca17439b4dd023625f8f22689c0432341986099
|
|
IF we cannot activate the ASP in response to an ASPAC, we should
return just the error and not an error + ASPACK_ACK.
Change-Id: I681021a13af9b91d8b2b849bd7149d6b1f783865
|
|
Change-Id: Ic99131489efaef87f882312a042f5feb6a60bb86
Related: OS#4220
|
|
Change-Id: I16ad0847d671522c8942b441db7e4c460f4f142b
|
|
Change-Id: Ic5bae0b69dcf24da8069709692b5687ad76239dc
|
|
Change-Id: Ibfae10a1e9385079db4b353e48a262bc8ab5230a
|
|
Properly transition into IPA_ASP_S_DOWN from IPA_ASP_S_ACTIVE
and fix the mask of legal out states from IPA_ASP_S_ACTIVE.
BSC-sccplite tests are still passing with this change.
Change-Id: Idb8e7bd1c74a4b47080fe32ebe0161c503ead571
Related: OS#3111
|
|
Testing with an actual SCCPlite MSC, I see the IPA connection starting out by
the MSC sending an IPA ID ACK. Make the ipa_asp_fsm match that.
Change-Id: Icffda98579e676ab6ca63c9c22cf5d151c4fe95f
|
|
In libosmocore Change-ID I1834d90fbcdbfcb05f5b8cfe39bfe9543737ef8f
we have introduced ipa_ccm_id_resp_parse() as a bugfixed replacement
of ipa_ccm_idtag_parse().
The main difference is that the returned "value" parts now have
a correct reported "length", whereas before this commit they all
reported a one-byte too-long "length" for each IE.
Change-Id: I3c79d3bb56cc1370b9922e64d13d2d5508fd8039
|
|
Ensure we don't pass a negative integer as "unsigned int len" to
ipa_asp_fsm_wait_id_get(). This could result in a remotely-triggered
integer underflow.
Change-Id: Idf9a5c0938e6ae6d47bf85ddfec3306fa3ddb3ce
|
|
When we destroy a FSM, we (logically) must osmo_timer_del() any running
timers that the FSM might have been using. This was not implemented
for xua_as_fsm, xua_asp_fsm and also missing from ipa_asp_fsm.
Change-Id: I670df831d7bc30de48ed4277648a461e1e1968fa
Related: OS#2668
|
|
Change-Id: I113232bbeaa7a835871df7f9b883ba573d8a2534
|
|
From the STP point of view: In order to be able to route messages back
to an IPA client, we need to create a route at the time we have
successfully identified the AS for this client based on the name
presented in the IPA CCM ACK "name" field. Once the IPA client is
destroyed, the route must be deleted again.
With this commit present, we can have an IPA client (such as
osmo-bsc-sccplite) connect to OsmoSTP and exchange BSS[M]AP
with an M3UA-speaking osmo-msc. Basically, the STP reaches
the point where it can translate between IPA-style SCCPlite
and proper M3UA/SUA on the other side.
Change-Id: I901f06c5d0f2eae60f8d931215ed65190330ce66
|
|
If for some reason we cannot resolve the file descriptor for a given
FSM, we shouldn't attempt to send data through it.
Fixes: coverity CID#167155, CID#167154, CID#167153, CID#167152, CID#167151, CID#167151
Change-Id: I8b1a676b653bcdad21cb7927d549f499950a2b73
|
|
This tries as good as possible to fit the IPA/SCCPlite stacking into the
existing SIGTRAN/SS7 code architecture/model. To the user, the IPA
protocol looks like yet another protocol on the same level as the choice
between SUA and M3AU. On the inside, things are obviously quite
different.
We need to handle TCP with IPA framing instead of SCTP for both server
and client. We also implement an alternative "ASP FSM" for IPA, which
takes care of the CCM handshake (ID_REQ/ID_RESP/ID_ACK/ID_ACK2) for both
client and server mode.
In server mode, we use the 'unit name' as identifier to look up the AS,
similar to how we use a routing context to look up the AS in the xUA
case.
We also have to bypass activating the default layer manager in the
simple client to make sure we don't run into even more complexity.
What's missing right now is some way to manually override/set the point
codes. As IPA/SCCPlite is missing any routing label, we currently
simply generate one with SPC=0/DPC=0, which will obviously not work in
most configurations.
Change-Id: I9098574cddeba10fcf8f1b6c196a7069a6805c56
|
|
I don't think the order of messages is that important (and specified in
the RFC), but let's do this to make the m3ua-testtool case happy.
Change-Id: I2e150e941a6fcfd203944f5b20bd07c07193f44a
|
|
For classic xUA this is not needed, as the server doesn't have to react
to establishment of the SCTP connection. The client will start with an
ASP_UP_REQ. However, in upcoming IPA support, the FSM will need to
react on this event.
Change-Id: Ib10914b27f8761ea44a0fdba96c045821223722a
|
|
When an AS goes "down" it first entres a recovery state, in which any
to-be-transmitted messages are enqueued until the timer T(r) expires.
Once the timer expires, the messages are discarded. If the AS goes
ACTIVE before timer expiration, queued messages are sent.
Change-Id: I22725bf35306299a00c66d7b3637f5e198c26247
|
|
This "default layer manager" can optionally be used by a xUA ASP. It
will handle the xUA Layer Manager (xlm) primitives and use them to
behave as follows:
* bring the ASP into state "INACTIVE"
* see if the SG can match our connection (based on IP address + port
information) to a statically configured ASP configuration with
associated AS(s). If yes, it will send us a NOTIFY message with
AS-INACTIVE.
* if the above doesn't work, try to dynamically register a routing key
using RKM for the point code that was locally confiured on the
ASP/client. If that works, the SG will now have created ASP and AS
objects as well as a routing key and be able to serve us, sending the
NOTIFY with the AS-INACTIVE state.
* After either of the two above, we will attempt to transition into
ASP-ACTIVE. The SG should send us an AS-ACTIVE notification in return
* if anything fails, abort and disconnect the SCTP connection, restart
related FSMs and start from scratch
Change-Id: I78d4623dd213b5c59007a026a6cc3cfe5c04af50
|
|
This was discovered (and fix validated) using m3ua-sgp-asptm-i-005 of
Michael Tuexne's m3ua-testtool.
Change-Id: I217ae287e22371e36dda0f87a7737b62fb1bf2d6
|
|
This was discovered (and fix validated) using m3ua-sgp-asptm-o-003
of Michale Tuexen's m3ua-testtool.
Change-Id: If231072655170fe52dae738882dd63b1d0a60cf9
|
|
This was discovered (and fix validated) using m3ua-sgp-asptm-o-001 of
Michael Tuexen's m3ua-testtool.
Change-Id: I6d254f7a33856e036329aa717a9c03efb1f1289d
|
|
Change-Id: Ibcda68b7acb02bf1580a832baff06ff21cbac713
|
|
This was discovered (and fix validated) using m3ua-sgp-asptm-i-004 of
Michael Tuexen's m3ua-testtool.
Change-Id: I76c01189b75ff3084cd4d3944314ec9b9f811dbf
|
|
Change-Id: I2904f8ebd97036690ba8a9525b31354c0252123b
|
