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
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
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 DUPU message in SUA and M3UA indicates the unavailability of
a (MTP-level) user, i.e. the entire SCCP, ISUP, ... is not available.
If we receive a DUPU (destination user part unavailable) message in ASP
role, then we must
* distribute it to any other ASPs for which we operate in SG mode
* pass it as MTP-STATUS.ind to SCCP, which can then generates
N-PCSTATE.ind to the SCCP User
Change-Id: I1559ed0f761a8495b222df48c6bd43798e220471
M3UA and SUA have one sub-protocol called [S]SNM, through which the
SG informs the ASP about certain destinations (point codes) becoming
available (DAVA) or unavailable (DUNA) in the SS7 network.
This patch adds support for
* generating DAVA/DUAN on a SGP when the AS FSM changes to/from AS-ACTIVE
* receiving DAVA/DUNA on an ASP and informing other "SG role" AS/ASP
* processing DAUD from ASP received by SG, generating relate DAVA/DUNA
responses
Related: OS#2623
Change-Id: Id92be4691b0fd77598a6edb642c028bbd8c5b623
When receiving user-data (connectionless / connection-oriented),
we must make sure that there either
a) no routing context IE in the message, and only one AS within the ASP, or
b) a valid routing context IE for an AS within the ASP
This important input validation has been done in M3UA for a long time,
but somehow never been implemented on the SUA side so far.
Change-Id: Icc232250513009137add3b45fecbb5d2a07c0645
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
RFC3868 states clearly that DATA messages MUST be sent o a stream other
than stream '0'. So at the receiver side, we should validate that (just
like we do in M3UA.
Change-Id: I0784e221ef791557a69be04f7d246de059ea84c8
The general rule for 'struct xua_msg' is now that it is free'd by the
function that also allocates it in the first place. Any downstream
consumer of the xua_msg may interpret it, but not hold any references or
free() it.
Change-Id: I708505d129da5824c69b31a13a9c93201929bada
If we use the infrastructure provided by osmo_ss7 on the lower layer and
the SCCP SCRC, SCLC and SCOC code on the upper side, not much of the
original sua.c code remains. It looks much like the M3UA code now.
Change-Id: I193b74f58aa70c443ae17e78b5604246d6bc3f71
We fill in the data structures of a xua_msg_dialect and make use of it
for generic mandatory IE checking and messageheader printing.
Change-Id: I966103f30b9be247ba6905ba8e06b87654d9981a
libosmo-sigtran is GPLv2-or-later, there were some files that
accidentially had an AGPLv3 license header, which was a copy+paste
mistake at that time.
Change-Id: I67dfd0ae6157afafd3873a3baaa4c6107c04ddfd
For the N-DISCONNECT prim, parse CREF, RLC and RLSD from the proper parameter
struct type: osmo_scu_disconn_param instead of osmo_scu_connect_param.
Before this, the conn_id ended up in the wrong place and the other side always
received a zero conn_id.
Tested only for the RLSD case, which fixes Iu-Release message evaluation for
all except the very first SUA conn received by the CN components.
In all three cases, set:
* param->responding_addr to conn->called_addr.
* param->originator to OSMO_SCCP_ORIG_UNDEFINED.
Change-Id: I446f2fe57cc3b7c52723f3ab82836513a5d37752
In order to receive a Paging command with a valid RANAP SSN, decode the SCCP
source and destination address IEs. This is used by hnbgw to forward a Paging
from CN to RNC.
This may be done more generally as soon as more IEs need parsing of their sub
parts. For now, iterate the higher level IE's data chunk and obtain the address
sub part IEs without storing sub part locations.
Change-Id: I03d0c2a9003fda59c5b88c8738df009c30fbc11c
disconnect is not a class3/4 operation. We simply generate + send the
DISCONNECT.ind message to the remote side and drop all local state about the
connection.
Change-Id: I4e336f9dfd4ebd0122cd9e5a70db3d05e9dc1764
... which can be resolved from the primitive call back prim_cb() by
calling osmo_sccp_link_get_user_priv().
Change-Id: If4c0f96f0621fb2adf4c78dc5994d3398431d92f
When server creation failed, besides closing the fd also return an error,
instead of continuing to use the NULL srv.
Change-Id: Iabfae7e5a880d10e4050da4945200ce9b848e577
Fixes: coverity CID#57684
There are some compiler warnings about other unused variables which we
rather keep as a reminder that the SUA code is partially incomplete and
should be finished at some day.
Change-Id: I42b76351f1bbdfb7fe339d5fad98c5a065822a45
hwelte requested this change for the addition of libiu in openbsc. In a
conversation we came to the conclusion that a rename of these two opaque
structs would suffice.
This is the "upstream" rename and will require adaptation of:
* the sysmocom/iu branch in this repository
* the iu related branches in openbsc.git
* the hnbgw and dummy_cn code in osmo-iuh.git
See https://gerrit.osmocom.org/#/c/192/2/openbsc/src/libiu/iu.c@57
Change-Id: Icbf64dd96f8e0e27695df73d1144519b88360b94
The fixme is about an actual message sent back, not about the error log.
Change-Id: I6de8fb202c7beb025232e9b97605e9f46778506a
Reviewed-on: https://gerrit.osmocom.org/228
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>