Otherwise when configuring ss7 instances in numerical order in the VTY
and then printing the VTY configuration they end up ordered this way:
cs7 instance 2
cs7 instance 1
cs7 instance 0
Related: SYS#5912
Change-Id: Id4d0a20cc5b0811b505b2d1051d496f8bd17d54c
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
Add a new function similar to osmo_sccp_addr_by_name, but search in a
specific ss7 instance's addressbook instead of searching in the global
address book. This is needed for osmo-bsc-nat, which uses two separate
instances at the same time.
Related: SYS#5560
Change-Id: I0f38b0d038b0dd8cd355e7284e5b56d438811bd9
The current implementation of osmo_sccp_simple_client forces the ASP to
run in ASP role. Even then when the user has configured it differently
via VTY. The osmo_sccp_simple_client should respect the VTY
configuration.
Change-Id: Ib57c513407747d36e503a4fb01c50c69dea0cb85
Related: SYS#5796
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: Ia450b630e0b60b38835f599c93985bbe97c50d2f
When introducing rate_couters, I forgot to call
rate_ctr_group_free(). I thought free'ing the parent object
via talloc is sufficient, but that obviously misses the point that
rate_counters have an internal linked list from which they must be
unlinked.
Change-Id: I8d27f025c22776d0153d867e36c073ef716eb974
This avoids log messages like
DLGLOBAL <0016> rate_ctr.c:92 'sigtran.as' is not a valid counter group identifier
Change-Id: I08666a1c3c1345cd3b0e55d544f6ac4a6df62fbf
This adds some very basic rx/px rate counters to the SS7 AS and ASP
OsmoSTP> show rate-counters
SIGTRAN Application Server 0 (as-rkm-1):
rx:msu:total: 86078 (1888/s 86078/m 0/h 0/d)
tx:msu:total: 0 (0/s 0/m 0/h 0/d)
SIGTRAN Application Server Process 0 (asp-dyn-0):
rx:packets:total: 86081 (1888/s 86081/m 0/h 0/d)
tx:packets:total: 5 (0/s 5/m 0/h 0/d)
Change-Id: Idb811ca81adfe47152d484f6b981e661dc569e15
XUDT and XUDTS can be used in two situations:
a) because the sender wants to use segmentation
b) because the sender wants to include a hop counter
In this patch, we implement support for case "b" only.
Change-Id: Ic5b9486f1aeb4bb90cfe702a7ce996f5d82ded2c
Related: OS#5281, SYS#5674
Allow user apps to relay the decision of proper default local/remote
hosts values to the library. Proper configuration of these addresses can
be quite cumbersome to get correctly, or confusing at least. That's due
to the multi-homing feature of SCTP where both IPv4 and IPv6 are
involved.
We were already doing this kind of automatic setup in
osmo_ss7_vty_go_parent(), where we do validations and assign addresses
based on IPv6 availability.
On the other hand, apps using osmo_sccp_simple_client_on_ss7_id() API
usually pass "localhost" as default address. In Linux, when IPv6 is enabled
localhost is resolved as "::1", and "127.0.0.1" when IPv6 is disabled.
Let's instead allow apps to relay the setup to the lib, so same addresses
can be applied both during VTY command as well as if there was no VTY
setup at all.
Related: OS#5186
Change-Id: I82e203612571b7651d758d8148661f706a1642ba
Fix wrong header and swapped user / cause values (see RFC 4666). This
makes TC_ssnm_distribution_dupu pass.
Change-Id: I717b64d13d12a2781c90e4d2f83643331797bed4
m3ua_tx_xua_asp will at some point convert the xua msg to a msgb by
copying and then send it, the xua msg still needs to be freed by the
caller.
Closes: OS#5185
Change-Id: Id8584b99f30f2db602d4d129e4114821697272ab
When libosmo-sigtran runs in ASP role, then the entire routing table
introspection (show) and routing table configuration VTY commands are
not present. Editing the routing table manually only makes sense in SG
role, but it is still useful to be able to inspect the routing table in
ASP and SG mode.
Change-Id: Ieaef4f0344b5b77ff5047013e9da1e938004e97c
Related: SYS#5392
Operators may set up a routing key in each AS node. However, this does
not mean that there is also a route added to the routing table. If the
default route is not sufficient (e.g. if multiple AS are defined), then
operators are epected to put matching routes into the routing table.
However, when libosmo-sigtran runs in ASP role, the VTY commands that
allow to routing table changes are not present.
In an ASP role we are in an endpoint situation, so no complex routing
is required, in most cases (single AS) even the default route is enough
but to ensure that each AS will get a route, add routing tables
automatically when running in ASP role.
Change-Id: Ic60b36983232308250e591dbad576aaafdd6b586
Related: SYS#5392
The behavior here since to have changed at least a couple times in
history, always apparently breaking some compatibility:
* libosmo-sccp.git a0dd986f55
(SCCPLite MSC sends IPA ID ACK at startup) [10th July 2018]
* libosmo-sccp.git 9c0fae14d1
(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
There are implementations out there which send us traffic, specifically
in this case SCMG (SST) that has only SSN in both Called and Calling
Party. This means the inbound SST message is routed correctly to the
local SCCP user of libosmo-sigtran. But when that local SCCP user
responds with inverting Called/Calling Party, the new destination again
just contains a SSN.
As a result, we don't know where to route the message (we always need a PC).
Change-Id: Id66ae960ebe3cb3b09c6dd5454f9ac9c073f46d7
Closes: OS#5146
This quirk allows the M3UA + SUA code to accept SSNM/SNM traffic despite
being in AS-INACTIVE state. This is forbidden by the RFCs but there
are some implementations that apparently just don't care what is
specified.
Change-Id: I193dd546b3e3c00e29f192d0d1bf7819b3e194be
Closes: OS#5148
The M3UA RFC talks about this message being used in ASP->SG direction,
not the other way around.
Closes: OS#5147
Change-Id: I36ff172b47142a877b37bbd149073bef35b36a74
A quirk is an implementation work-around in order to establish
interoperability with another implementation, either a buggy one or
one that follows a different interpretation of a given spec.
For now, we introduce a first quirk affecting when we (in ASP role)
send an ASP-ACTIVE message to the SG.
Closes: OS#5145
Change-Id: Idd947ea39d743eb1bc9342ad9d098036821da45b
We currently use the local connection ID on the SCU SAP also as local
reference on the wire-line SCCP messages. However, the latter only has
a 24 bit range, so we should make sure to wrap accordingly on
allocation.
Change-Id: I414d29271da48ac0b05a688ce9e949a66e4d0d92
Closes: OS#3921
Related: OS#3871
In IPA, unlike M3UA/SUA, we often have clients connecting from
random/unknown ports. In such cases, the configured remote port is '0'.
Let's use getsockname to determine the actual source ip/port of the
connected client (if any) during "show ... asp"
Change-Id: I1327a46d0b74c572d2ad828a958090af53b9fa37
Closes: SYS#5429
It's confusing to keep around a string representation of what peer the
socket was previously connected to.
Change-Id: I00d47fc355bfe24915653767ad75c1f491c060d5
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
The current code would potentially delete a route that was statically present in the
configuration in the following situation:
* route exists in config
* identical route is attempted to be added at AS-ACTIVE time, but fails
* route is unconditionally deleted at AS-DOWN time
* user now does 'write file' and has lost a route
Let's make sure we only delete the route if we added it previously.
Change-Id: I9ad5f7ebe0790e6c186b8ea1b12f204860a00cd2
Related: SYS#5422
Otherwise we run into the problem that a route with mask 0xffffff
differs from one with a mask of 0x3fff despite having only 14 bit
point code length and them being logically equal.
Change-Id: I5d5c828de45724d93a0461bb0dd7858fd8378acd
Related: SYS#5422
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
Pau Espin
Harald Welte
Oliver Smith
Philipp Maier
Eric Wild
Vadim Yanitskiy