SUA allows references of 4 bytes, but SCCP/M3UA doesn't.
SUA: RFC3868 sec 3.10.4:
The source reference number is a 4 octet long integer.
This isallocated by the source SUA instance.
M3UA/SCCP: ITU-T Q.713 sec 3.3:
The "source local reference" parameter field is a three-octet field containing a reference number
which is generated and used by the local node to identify the connection section after the connection
section is set up.
The coding "all ones" is reserved for future use.
Related: SYS#6211
Change-Id: Ia547346bdae54a032d2198ecd4972fb3f8dd073e
The length limit of optional Data parameter is 130 bytes according to ITU-T Rec Q.713 §4.2..§4.5. If we receive CR, CC or
RLSD message with bigger data - cache it if necessary and send via separate DT1 message after connection becomes active.
Fixes: OS#5579
Change-Id: I0033faf9da393418930252233ce74d62cd1cef8a
SCCP RLSD message might have up to 130 bytes of optional data according to ITU-T Rec Q.713 §4.5 - add helper which
allows sending it and use it in example code.
Related: OS#5579
Change-Id: I92ae22d2cab5863245fba3d904a300055fda34fe
Previously DT1 message sent via osmo_sccp_tx_data() was silently truncating data if it was over 256 bytes. Let's fail
explicitly and let caller handle this.
Related: OS#5579
Change-Id: I8a67bc40080eb1405ab3b0df874e3ea20941a850
Add convenience helper to check if particular connection ID exists and use it to
properly report errors when attempting to send messages over non-existent connections.
Change-Id: Iffedf55b4c292ee6b2f97bcdeef6dc13c050ce01
Return proper error code from packet encoding routine and check for it before switching FSM state as it creates
confusing mismatch with actual protocol state.
Related: OS#5579
Change-Id: I8431c77632014e2551d1da779afddffcd1bb541c
Limit length of optional Data parameter to 130 bytes to conform with ITU-T Rec Q.713 §4.2..§4.5 while receiving SCCP messages.
Related: OS#5579
Change-Id: Icc3bd0a71b29cf61a259c5d97e7dd85beb4397bd
This is similarly done for same IE in other functions, so let's do it
here too in order to make coverity happy, and avoid random access ptr
probably ending up in obscure crash.
Fixes: Coverity CID#272994
Change-Id: I72059ffaa608bb4f5c4bd274645878e0b31ed6e0
If we receive any M3UA/SUA SNM SCON mesasages, distribute them
to any other active ASP to make everyone aware of the congestion
situation.
This makes STP_Tests_M3UA.TC_ssnm_distribution_scon pass and hence
should turn the entire osmo-stp test suite "green"
Change-Id: Iac7aeba980fbbd8b58f8872a29ba10745eb0a730
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
Pau Espin
Max
Harald Welte
Oliver Smith
Philipp Maier
Eric Wild
Vadim Yanitskiy